What you are saying isn’t contradictory to anything I’m saying… ok so you must always have an active task list, well then prevent removing the last active task list from deskbar… arguing against increased flexiblity using features Haiku already has because “users might do something stupid, when when can easily prevent that” is ridiculous… it’s exactly the broken mentality that lead to Gnome’s mess where developers think they know best and users end up hating it.
Arguably whatever a user does while rearranging the Deskbar doesn’t matter anyway, as a direct method of resetting to defaults should be provided, in case their changes are indeed stupid. Some users may even prefer no on screen task list… instead relying entirely on the switcher or a switcher. That’s a very keyboard centric desktop user thing to do…
Indeed… do note that this is the forum, it’s not like I’m demanding this or that. The point of the thread is to throw out some wild ideas I think…
That said, it probably wouldn’t hurt me to get back to some C++ … I think C# has probably made me a bit lax. Oh, and my flash programmer arrived today so may get around to dumping that BeBox rom.
But if we want to support that, then we cannot assume there is a way to access an application-global menu from a DeskBar or something similar.
In general what I’m trying to say: when you add more flexibility, you cannot push each working mode to the full potential. Because either users wanting a no-screenspace-wasted, keyboard driven system, will complain that they have no way to use an application-global menu. Or, we don’t have said menus, and users of the DeskBar will keep requesting that nice feature. Which we can’t use because of some other users with a different workflow.
I’m not saying we shouldn’t try to do something that works for everyone. I’m just trying to point out where the difficulties may arise. There can be ways to solve this that makes it usable in all cases, in a consistent way for everyone. What’s important is that the goal of Haiku is to provide a coherent user interface, this simplifies the lives of app developers because they can rely on some features being there, and they can design their UI on that common base. The more you make things configurable, the more this common base shrinks. And the smaller that common base gets, the more apps will tend to reinvent things that should be handled by the system, because they can’t be sure how the system will make it available to users and wether this is suitable for their needs.
This is why we have to be careful with making everything configurable. Again, it does not mean we should not allow configuring anything. It is something we have to keep in mind when considering making something configurable, to make sure we keep our consistency, which is a key selling point for Haiku (and yes, also for Gnome 3. They got this wrong by trying to cover too many use cases, namely desktops and tablets in their case. Which is why we focus only on desktop machines).
Very true, but then… do all users use what is provided to the full potential anyway? Almost certainly not… so better to just provide good powerful defaults and let them remove what they don’t want etc…
I do find other systems that allow this sort of customization very dull I must admit… as there are typically no actual options or alternatives to the defaults, FireFox is a prime offender there these days. Instead of providing elegant alternative methods of doing things… each feature is monolithic and all or nothing. So, yes on the one hand it’s a minefield but perhaps one worth navigating.
It might make sense to pull out some of the Deskbar code into libraries or a “Deskbar Kit” to make it easier for people to make alternatives. Things like the customization of the context menu that pulkomandy mentioned should be a well-defined protocol (maybe some extension to the scripting support, or some other standard but optional message format that the Deskbar could query the app with.)
Also right now the Twitcher is inside the Deskbar, something I think should be fixed so that if someone uses an alternative to Deskbar they don’t lose the keyboard app switching. I have a ticket for that: https://dev.haiku-os.org/ticket/9544
Also long ago I know there were some good discussions about “Deskbar 2”. It might be here in the forum or maybe on the mailing list. I know Stephan (stippi) had some good ideas. I think the general idea was very much like how Windows taskbar works now, so app icons can be pinned, making LaunchBox less useful. In other words sort of a LaunchBox/Deskbar combo. Plus the customized menu thing. Maybe we don’t just want to blindly copy Windows though…
Plus I can see cb88’s point in having more components that can be put together rather than something monolithic.
If someone wants to work on an alternative DeskBar, that’s great, but I expect them to do this kind of work. It has no return value on its own. And given how old and ugly the DeskBar code is, it may be a better idea to write a library from scratch anyway…
Of course, really there isn’t any need to say so however, manyof us have been around the project for a decade or so. We’re just talking about different concepts because we enjoy doing so… that’s all. If a developer thinks it is interesting or if one of us decides to hack on it then cool.
Probably you’d have to use the Deskbar at the very least as a reference for what is required to be implemented though… It probably would be better to do the cleanup targeting R2 without GCC2 baggage though right? Unless there is an easy way out for that… perhaps GCC 2 only images would be excluded from using it and be stuck on the old Tracker.
OK, but practically, what difference does this make to us? Like I’ve said before, we largely are not interested in C++11 and beyond features; the only thing that comes with newer compilers is better performance for the most part.
That’s fine for now I guess? But the main reason behind that is GCC2 compatibility… not because there are absolutely no new features of use in newer specs. I mean yeah a lot of the recent stuff networking and memory model additions may not be of much use.
std::function and std::initializer_list are the only things of any potential use to us, I think. The later we could support (for GCC7-only, but still) starting immediately if someone submitted a patch. Largely that’s just a syntax change though.
There is a lot of value to newer C++ features, however, they are not necessarily fit to the existing kits in Haiku.
GCC2 compatibility is not a reason to anything. It’s something we have to live with for now. GCC2-only builds have long been deprecated (since we introduced WebPositive, more or less), and we are considering switching more components to GCC7 even in the 32bit builds, and even for R1 (app_server is a candidate if we are to implement complex font rendering using Harfbuzz, for example).
However, DeskBar hosts replicants, and currently this is considered a possibly useful part of the BeOS ABI, so DeskBar should stay gcc2 for a little longer. Or maybe we can reconsider this, if a survey shows that no one actually use closed source BeOS replicants.
Excuse my ignorance about BeOS compatibility and Haiku real code, but couldnt gcc2 relative things being in a chroot-like environment (just for backward compatibility) and have the whole remaining Haiku components in gcc7.x?
(i mean “remove” the gcc2 target/platform, in the long term)
You don’t need a chroot. Our builds are already hybrid and provide both version of libraries through some LIBRARY_PATH tricks.
However, the following components can load gcc2 code:
Kernel can load gcc2 drivers
app_server can load gcc2 accelerants (userspace part of graphics drivers)
DeskBar can host gcc2 replicants (for the tray icons)
Tracker can host gcc2 replicants (for desktop gadgets)
screensaver server and preferences can load gcc2 add-ons (screensavers)
media_addon_server can load gcc2 media add-ons
As you see, BeOS had a lot of components that would allow loading 3rd party code in their userspace. For these, as long as we want to provide gcc2 compatibility, we are stuck with gcc2. Now, we can decide that the compatibility does not need to go this far. For example, in the case of app_server, there is little need for reusing BeOS drivers, as most of them are either long obsolete or were open sourced (so we can recompile them). I think this is also the case for DeskBar replicants now?
The decor used in Gonx indeed is Be’s own creation, although it was just some UI exploratory work I think and they probably didn’t put much QA on it or they would have noticed the issue with the buttons.
I had the idea long ago to use a separate MIME type in the BDeskbar class, and use whatever app is set as default for it, it should make replacing Deskbar much simpler I think.
I noticed the same thing when playing with the Origin themes on Dano! It looks exactly like Gonx; my guess is the artist just put the buttons on the left in his design.
I was also wondering if Origin was ‘exploratory’ work, a testing thingamabob, or a working concept of sorts. Maybe it’s much like how Microserfs had the Watercolor and Plex/Jade styles for Whistler and Longhorn? It just has that odd sense of being experimental; maybe a step toward something. I do confess the title buttons are very hard to aim for; I actually press Alt+W to close windows most times when I have Origin set as the decor.
Maybe the finished R6 was planning to do something big visually? Makes me wonder, especially with the way the scroll bars and other parts of the window chrome change with it. And the pulsating highlights. Was Be going to visually tweak the UI when R6 came out?
Gotta admit, though, cool as Origin is, BlueSteel definitely feels easier to use with three buttons on the left side like Mac OS X, but honestly, it makes me wonder why Be would do that…
