Graphic library and GUI

1

Hi all!

I’m wondering if should be possibile to port on Haiku the “Enlightenment Fountation Libraries (EFL)”, and then use them as a base framework for the actual and an eventual new GUI (for the second and next releases). This library could be wrapped on standard BeOS API and next them could be improved to support all the thing EFL provide.

http://www.enlightenment.org/Libraries/Overview.html

I’m not asking to port Enlightenment Window Manager, that’s not! But watch at what these libraries can do! They created a very very fast window manager and it’s very looking fine! I think this could be the right way for Haiku too. We could create a very fast and usable GUI as the original one, but with a good style that could help beos from looking just “old” to newbies. And it also could help writing good and fast applications.

Bye
Hiei

2
Hiei wrote:
Hi all!

I’m wondering if should be possibile to port on Haiku the “Enlightenment Fountation Libraries (EFL)”, and then use them as a base framework for the actual and an eventual new GUI (for the second and next releases). This library could be wrapped on standard BeOS API and next them could be improved to support all the thing EFL provide.

http://www.enlightenment.org/Libraries/Overview.html

I’m not asking to port Enlightenment Window Manager, that’s not! But watch at what these libraries can do! They created a very very fast window manager and it’s very looking fine! I think this could be the right way for Haiku too. We could create a very fast and usable GUI as the original one, but with a good style that could help beos from looking just “old” to newbies. And it also could help writing good and fast applications.

Bye
Hiei

Just think of what you’ve said there. How could using a WRAPPED library make the GUI any faster? It’d only be wrapping the same GUI libs as are already there…

3

When I say WRAP I just say to “modify” the API interface, from C to C++. The lost in performance is very low. It isn’t the same from wrapping these libraries from C to Python or from C to Java. These libraries has been created exactly to be used as low level API for a GUI, to be “Fast, light and performing libraries”, and I think they are what haiku needs, not for first release, but if it want’s to become a competitive alternative to windows, osx and linux, it needs a good look & feel without loose responsivity and speed.

4

But Haiku’s graphical API already using a backend - AGG - to do low level drawing. And based on my experience of Enlightenment, its going to be far faster than anything Rasterman wrote…

Also, are you suggesting the Be API is C there, or that the Enlightenment libs are C? Because the Be API is most certainly C++…

5

Yes, AGG is a nice library for R1, and will provide such features as fully antialiased drawing throughout the entire OS.

The major change of rendering backend I can see happening is a switch to a hardware-accelerated OpenGL one, that I imagine would be written from scratch. Could be wrong though.

6

I know BeOS API are written in C++, and also that actually AGG is used for Haiku R1. But AGG doesn’t appear to be a library designed for GUI, its first three features, from the web site, are:

Anti-Aliasing.

Subpixel Accuracy.

The highest possible quality.

And I don’t think that a desktop needs subpixel accuracy, and highest quality… It also doesn’t provide any hardware acceleration. EFL could use an OpenGL backend, and as tb100 said, it could be useful for Haiku R2.

I don’t know what you think about Rasterman, but I’ve been impressed from actual alpha version of E17!

7
Hiei wrote:
I know BeOS API are written in C++, and also that actually AGG is used for Haiku R1. But AGG doesn't appear to be a library designed for GUI, its first three features, from the web site, are:

Anti-Aliasing.

Subpixel Accuracy.

The highest possible quality.

And I don’t think that a desktop needs subpixel accuracy, and highest quality… It also doesn’t provide any hardware acceleration.

R1 will have the same amount of 2D hardware acceleration as R5 - screen to screen blits and so on. I think subpixel and quality settings of AGG can be controlled - so for most drawing of the OS, it will be set up for speed rather than quality.

8

Ok, my initial question was primary for curiosity… But anyway I think that could be useful to code the graphic subsistem considering the evolution it could take in R2. We’ll see in the future what will be the right choice. Anyway, I can’t wait anymore for Haiku to be ready!!! :wink:

9

ahoj! ako sa mas? this is my first post. i have seen how both haiku and enlightenment 17 are reaching maturity around the same time. i was curious if porting e17 to haiku would be amazing or what! so i googled it and found this thread. I know this thread is old as religion, but it asks some interesting questions. does anyone think that the decision here not to use EFL for haiku might not be correct anymore due to progress or changes in the two projects in the past 5+ years? I’m familiar with a tiny bit of programming, and quite familiar with operating systems, so it seems like it might be a good idea to me but I am not sure what problems might arise from the programming aspect of it. Personally, I love haiku, but it needs beautified some, it looks ancient. e17 and the EFL have some pretty nice features that have the same ideas as haiku about being lightweight yet powerful. what about just changing the gui code for the backend of the beos window manager? like I said, I’m not clear on the technical details, so I’m asking for anyones thoughts on the topic. cau

10

A modern, fully-accelerated display mechanism, would be wonderful, but it would be a shame if it compromised Haiku’s existing visual language and crisp aesthetics. The current design seems to convey an understated but playful elegance that invites user exploration. Simplicity and minimalism are timeless, perhaps.

11

So add those EFL features, but don’t bloat the system for needless eye candy. its always better to extend the API vrs changing it like underwear or boxers.

Linux hasn’t gotten to beta 1 yet, despite claims to the contrary.

12

I’m not sure why someone was suddenly compelled to necro this thread, but…

Linux 1.0 is almost seventeen years old.

A “beta” is the feature complete test phase. It certainly is remarkable that after nearly a decade Haiku still isn’t feature complete even judged against the rather low bar set for it at the start of OpenBeOS. But Be were never much better, later releases were all shipped by feature trimming, ie you set a deadline and you just rip stuff out until you hit that deadline. This means there’s quite a contrast between the optimism of previews and the reality for anyone who bought it.

13

[quote=NoHaikuForMe]I’m not sure why someone was suddenly compelled to necro this thread, but…

Linux 1.0 is almost seventeen years old.

A “beta” is the feature complete test phase. It certainly is remarkable that after nearly a decade Haiku still isn’t feature complete even judged against the rather low bar set for it at the start of OpenBeOS. But Be were never much better, later releases were all shipped by feature trimming, ie you set a deadline and you just rip stuff out until you hit that deadline. This means there’s quite a contrast between the optimism of previews and the reality for anyone who bought it.[/quote]

Linux is a kernel. As far as kernels go I don’t really agree with the statement that its not a beta. To actually achive beta you’d first have to stop breaking the abi and api on every release. Having a undefined set of broken and halfass implemented features is not a good thing.

exactly what features is haiku missing ?

14

[quote=thatguy] Linux is a kernel. As far as kernels go I don’t really agree with the statement that its not a beta. To actually achive beta you’d first have to stop breaking the abi and api on every release. Having a undefined set of broken and halfass implemented features is not a good thing.
[/quote]

You seem to be confusing the userspace API and ABI, which Linux preserves, and the internal kernel API and ABIs which are changed as necessary. Changes to the internal API and ABIs only matter if you are in fact a Linux kernel developer, in which case it’s part of your role to keep track, or if you develop out-of-tree drivers, which is frowned upon.

Both the userspace and kernel ABI evolve, but in different ways. The userspace ABI evolves only by growing, the introduction of the race-free openat(2) didn’t get rid of open(2) so programs which use open(2) will continue to function indefinitely. But the kernel ABI both adds and removes things. For example, back in the 1990s when Linux was made SMP a Big Kernel Lock was added, drivers had to be updated to use the BKL or they did not function correctly on multi-processor machines. Now the BKL is being removed, it is optional in new releases, so new drivers should use a more fine-grained lock (or create one) instead. But nothing changed for userspace applications by this process.

In real terms the list is huge, but sticking just to OpenBeOS as conceived it really comes down to just two, application compatibility with BeOS (still some BeOS programs won’t work for one or another reason) and hardware compatibility which means Haiku itself doesn’t work for some people.

15

[quote=NoHaikuForMe]
You seem to be confusing the userspace API and ABI, which Linux preserves, and the internal kernel API and ABIs which are changed as necessary. Changes to the internal API and ABIs only matter if you are in fact a Linux kernel developer, in which case it’s part of your role to keep track, or if you develop out-of-tree drivers, which is frowned upon .[/quote]

Thanx for proving my point. The driver function problem alone is madening enough.

Oh hoseshit, they still break the usespace ABI and API all the time, Which is why very few commercial third party apps get developed. Companies don’t want to chase a moving target and have to constantly rebuild there apps every kernel release.

In your terms the list is huge. In the communitys terms the list is small. Aot of the features you claim haiku is missing are features that simply aren’t needed by desktop users to begin with. Did it occur to you that Haiku users don’t want a linux like OS in most ways.

I can agree on 2 features one of which is simply a bug hunt.

16

Really? You don’t seem too bothered about it in Haiku.

Concrete examples please, of how the Linux kernel “breaks” its userspace ABI and API “all the time”. Any?

Commercial apps like Skype, you mean? Which I installed on a laptop for someone last year, and, despite several kernel upgrades, the same exact version of Skype is running just fine? Or games like World of Goo? Maybe Oracle? Or something like Frame Thrower?

[quote]
In your terms the list is huge. In the communitys terms the list is small. Aot of the features you claim haiku is missing are features that simply aren’t needed by desktop users to begin with. Did it occur to you that Haiku users don’t want a linux like OS in most ways.[/quote]

Here’s five randomly chosen features, which of these “simply aren’t needed by desktop users” and why is this claim any different from saying they should stick with MS DOS 5.0 ?

• Colour Management
• Hotplug SATA / eSATA drives
• Network file sharing
• Hardware 3D acceleration
• Firewire soundcards

17

[quote=NoHaikuForMe]
Really? You don’t seem too bothered about it in Haiku.

Concrete examples please, of how the Linux kernel “breaks” its userspace ABI and API “all the time”. Any?

Commercial apps like Skype, you mean? Which I installed on a laptop for someone last year, and, despite several kernel upgrades, the same exact version of Skype is running just fine? Or games like World of Goo? Maybe Oracle? Or something like Frame Thrower?

Here’s five randomly chosen features, which of these “simply aren’t needed by desktop users” and why is this claim any different from saying they should stick with MS DOS 5.0 ?

• Colour Management
• Hotplug SATA / eSATA drives
• Network file sharing
• Hardware 3D acceleration
• Firewire soundcards[/quote]

I am tired of multi qouting you its getting pretty god damned annoying and frankly your pretty annoying.

In this order.

Driver support in haiku at this point of the project should be expected to be poor. Only becuase thats the LASt thing the Os team should be working on before APPs. I will say that on average the standard haiku drivers that work, are more useful then the linux counterparts.

You need concrete examples ? Wow your fanboism reeks. go look at the damn bug tickets on a kernel update.

Wow, how that photoshop support ? Microsoft office " even apple has MS office "

what apps again ? Oh thats right, server software or shitty toy apps. Got it.

To adress your 5 random short falls " which are debatable.

  1. color management.

this is a hack of colosal proportions. Its like applying compression on audio to try and correct a source volume issue.
Try finding and using the Menu button on your monitor and buy a test pattern from a AV store. If the input is wrong, color correcting it for display will only screw it up at the time of printing.

If the printer needs color correction, its defective.

  1. Hot pluging of sata/Esata drives.

yep lots of non server people hot plugging drives all the time. In fact its one of my favorite pass times. Take the drive out and put it back in. Hmmm I think this is a red herring for 90% of computer users.

  1. network file sharing.

Yeah so whats your point. Its a single user system. Its not a server OS. If you want a server OS maybe you should stick with linux. There is a semi functional Samba port that could likely be brought up to full operation quickly when r1 gets closer.

  1. Hardware 3d acceleration.

Yes this would be nice. But unless you do 3d gaming " which users statistics indicate 70% of PC users don’t. Its a moot point. but its not like anyone but windows has gaming covered. Last I checked they were the only OS with modern 3d gamming. don’t even decry linux having 3d gamming. Its a joke and the same games are already ported or are being ported to haiku. There is work on the gallium3d driver stack port to, but its been dormant for sometime.

I would argue mode setting capability is far more pertinent.

  1. firewire sound cards.

Yeah lots of firewire audio devices, mostly studio based.sound like a real concenr with the whole 1% of the PC market being used for audio recording on multichannel firewire devices. Most of which are being phased out for usb 2.0 and now usb 3 and then theres the overwhelming fact that the maudio and other pci cards are vastly more popular and better quality.

so to redress, Haiku doesn't meet your needs, which is fine. Since it doesn't meet your needs maybe you should troll on back to a linux website where you guys can all sit around and egostistically masturbate each other on your bash skills and file sharing prowess with your uber broken distrobution scheme multiple window managers and non interoperable Os landscape.

Enjoy your self and don’t hurt that shoulder patting yourselves on the back. Its only taken 20 years for Linux to still not be a prominent desktop OS.

18

Yes, concrete examples, not an ad hominem attack. This would only be difficult if you didn’t have any, in which case your assertion that this happens “all the time” would be entirely unjustified.

ABI compatibility is a big issue for Haiku, so it’s certainly worth having an opinion. But it is most helpful if the opinion is informed by the facts.

19

[quote=NoHaikuForMe][quote=thatguy]
You need concrete examples ? Wow your fanboism reeks. go look at the damn bug tickets on a kernel update.
[/quote]

Yes, concrete examples, not an ad hominem attack. This would only be difficult if you didn’t have any, in which case your assertion that this happens “all the time” would be entirely unjustified.

ABI compatibility is a big issue for Haiku, so it’s certainly worth having an opinion. But it is most helpful if the opinion is informed by the facts.[/quote]

Are you seriously trying to actually wage a argument the the linux kernel is api and abi stable ? Are you fucking high ?

Like I said. If you want proof, just start pulling bug tickets about kernel upgrade breakages. Its about that simply. There are a few thousand in the system.

Haiku has a ABI issue ? sometimes it might. But then it doesn’t claim to be stable or ready for release now does it.

you should stick to linux. you’ll be happy over there with your big gaint buggy kernel.

20

The Linux kernel does a great job of maintaining userspace API and ABI compatibility, as I explained. This has been somewhat important to its success.

Concrete examples are what I asked for, not vague references to “thousands” of bug reports.