ROS design suggestion

The place to bring up any design issues, or post your own creations

Moderator: Moderator Team

Do you like it?

YES, I really like it
66
81%
it's not much better than the old one
12
15%
NO, I don't like it at all
3
4%
 
Total votes: 81

oiaohm
Posts: 1322
Joined: Sun Dec 12, 2004 8:40 am

Post by oiaohm » Wed Nov 09, 2005 1:17 am

Have you ever used shell replacements under windows.

All right first version does not have to have a all powerful desktop system.

Big problems with shell replacements is that stuff just does not work right.

Alter System dlls is not the way. Reason I go and replace a system dll and X program adds its own custom version causing the new shell to crash.

Now ros explorer itself will not be played with. Menu Layout Entry boxs so on could be all in a xml file or something less. Themers and Coders.

If enough power is provided shell replacement its not required in most cases.

My question is what should theme writers be able to do? Ie no coding knollage at all. Build theme change the layout of start menu desktop and the like just by changing a file.

This allows a lot more people to experment with the GUI and someone not a coder might find a really good one.

Windows Themes are extreamly poorly created. Windows Themes is a vial hack. It just over rides registry entrys all over the place. Most Linux windows manager use a theme file ie I wish to use X theme so I get the infomation about what I wish to do from that theme file.

I will give you a good warning about Windows Themes never set sizes of everything in the registry to 0 or you are stuffed even in safe mode.

Good theme system there will be a partical theme for safe mode that cannot be changed ie so users cannot lock themselfs out with themes.

Nasty fact about windows themes is that you can edit any registry entry hmm let stuff the boot up because we used a stuffed theme file.

Since the old system can be very harmful we might as well take the chance to look at it and see how it can be rebuilt for the better even consider new features. Ie theme writers under windows have all the features they should have no reason to play with and lack the very features required to really let them play with the UI.

I am supprised that no virus writer has not created a virus windows theme yet.

Floyd
Posts: 300
Joined: Sat Nov 27, 2004 7:45 am
Location: The frozen part of the USA

Post by Floyd » Wed Nov 09, 2005 4:18 am

oiaohm wrote: Now ros explorer itself will not be played with. Menu Layout Entry boxs so on could be all in a xml file or something less. Themers and Coders.

If enough power is provided shell replacement its not required in most cases.

My question is what should theme writers be able to do? Ie no coding knollage at all. Build theme change the layout of start menu desktop and the like just by changing a file.
i think theming windows in this manner would be extremely cool.

the .xml file could define not only the resources (graphics, sounds, cursors) but also the button layout of the start menu. this would not be so much as a shell replacement but it would be adding power and flexibility to the default shell. oiaohm that's a great synthesis of ideas.

granted this not a "priority" but it gives us non-coders something to discuss.
:D
pax mei amici amorque et Iesus sacret omnia

Ratteler
Posts: 28
Joined: Sun Oct 09, 2005 4:31 pm

Post by Ratteler » Wed Nov 09, 2005 8:13 am

If you're going to to THAT far, why not do away with Expolorer all together and make it's replacment an AJAX DTE in a browser window.

That's actually not a horrible idea now that I think about it. Assuming that the browser isn't Typhoid IE with all it's vulnerabilities. It could LOOK like any DTE we want. All the work would be transportable to other OSs, and you could access your DTE from anywhere via a Personal web page.

oiaohm
Posts: 1322
Joined: Sun Dec 12, 2004 8:40 am

Post by oiaohm » Wed Nov 09, 2005 8:40 am

Minor problems Ratteler.

Windows Programs expect to find explorer to do things.

AJAX would cause overhead that could not be cached out.

Speed programmers would not like this at all. .xml to start menu could be cached out in most case once off cost on boot and when entrys change in the start menu rest of the time no speed cost. What ever is done has to be complied by the theme system or able be cache to reduce speed cost.

Javascript could always be changing.

Yes and this could not be IE to many problems.

Keep the ideas coming normal AJAX might not cut it but .net version might from mono if they ever get the native build option. Nothing with a bit of thought we most likely can work our way around the problems.

Speed vs Flex always a hard line to work out.

Lucractius
Posts: 47
Joined: Fri Oct 21, 2005 4:27 am

Post by Lucractius » Thu Nov 10, 2005 5:20 am

Must make mention of this point not only is it speed vs flex

its flex vs learning curve to USE the flex

ive been stumped for years now trying to understand how to learn to make these beautiful themes with things like LiteStep and enlightenment and ive always failed to get it... i understand the way they do it... and with lots of manuals and trial and error i could probably get to what i want... but the use of any kind of text file based GUI configuration MUST be complemented with GUI based tools to manipulate it... the concept of trying to conceptualise complex GUI interfaces in your head while working with a complex multilayer text file is well... arcane... just look at litestep themes. they have structure and yes, you could learn it. But when a user wants the flexibility, they shouldnt have to start climbing a steep learning curve to get it. some kind of even basic GUI "designer mode" fullscreen manipulation makes this very simple, and as long as its kept out of the way, prevents accidental use, No binding it to a hotkey by default!

just my 2 cents on the xml config idea.

oiaohm
Posts: 1322
Joined: Sun Dec 12, 2004 8:40 am

Post by oiaohm » Thu Nov 10, 2005 9:04 am

Good point Three Factors

Speed vs Flex
Flex vs Tool to use Flex.

Not all the Flex features might be in the general GUI editing tool ie new feature added and GUI editing tool has not caught up.

Major reason for readable config file so you can see what is going to do.

Big problem with windows themeis that the theme files alter to registry with features the theme editor does not show.

Ie the theme editor must have a section to display any unsupported features text. At least it give the user a chance.

I will give enlightenment and LiteStep are tricky at times to create themes.

Lucractius
Posts: 47
Joined: Fri Oct 21, 2005 4:27 am

Post by Lucractius » Thu Nov 10, 2005 3:12 pm

Any such tool should as you said give the user a chance to deal with any non standard definitions, which is why i think it might be best going with an XML one. since theres already a plethora of XML based formats that can be used to create anything from link lists, to rss feeds, SVG graphics, and pretty much anything else you want it to do. The GUI editor can ignore elements it doesnt understand while still being able to parse any kind of relationship they have with other GUI elements.

If a new feature element is docked to one the GUI does understand then it should be able to understand that Both need to be moved.

I think all this may be getting ahead of things unless we want to start working on definitions... which reminds me... the KDE Plasma Project is a very interesting thing to check out when examining where GUI will be going.

A Windows Lookalike is all well and good, but who says we should be coding ourselves into a corner that leaves us without the ability to explore new directions. Who knows, mabey once the compatibility goes up ... to about 80% and the word gets round... there will be a gradual shift to a "standard" windows platform embodied by Wine and ReactOS and programers will start using that for apps as opposed to the MS ones. At that point... would you want to find that you couldnt begin offering flexibilty in certain things cause of choises made earlier?

oiaohm
Posts: 1322
Joined: Sun Dec 12, 2004 8:40 am

Post by oiaohm » Fri Nov 11, 2005 1:13 am

Not all expandable defs are XML there are a few other options.
Ie I am just leaving the door open at this point incase someone knows of a better one for speed or something. I suppect long term Xml with cache system will most likely be the out come. Ie Section of code processes the XML creating the dialog resouces in a theme dll for the old system. And for the Xaml system XML to XML translation. Same theme two different caches depending on machine.

Flex selections made now and into the furture are really a starting point. Lets look fvwm for example started out as a verry plain windows manager with little amounts of flex. Now its extreamly flexable. Problem no good theme creator.

Common problem of Linux Desktops lack of good theme building programs.

Now starting from scratch done right should at long last see the Linux promise of the user customisable desktop that a user can control.

Serously I was more after how far theme writers want to go and the tech limits. Reactos need to be able to run on low ammount of ram for some applications. Low the GUI use of ram the better in some cases. Flex and speed have to be consided. Question is how much power can be given theme writers go without a bad effect on the system. This even includes thinking up methrod to cost the least amount of speed cost but give the most to the theme creators. Next Question how far should we go for high end systems ie how much do the theme writers want.

Ie this is two halfs. Low end systems and High end systems. The theme system if able should extend all the way from low to High with the same theme files. Ie disabling features to gain speed on low end systems.

First target of reactos is most likely low end so we cannot break that just for the power of themes. In furture yes.

All this has to be consided to be able to guess at the right system.

Most important of all the system must support expandion in case a feature that was not included is found to be needed by theme writers.

It is a option if there is enough intrested and we have nailed down some extra features seam able to done without major speed cost. That I would suggest a temp fork of ros explorer to develop theme related extentions and alterations. Ie if it works out merge it back.

This is not really to the point of complete build from scratch more what can we add now and what theme creators want added. Even the most AJAX idea that I kinda stomped on because I cannot see anyway of doing it soon[I am sorry for stomping as hard as I did]. Should still endup on the list.

Yes I am trying to get to the Definitions slowly and carefully.

I guess most people here are trying to reshape the desktop all the time due to lack of features in the Windows Theme system. Provide the features start a theme submit system get them out of the core developers hair. Ie make everyone happy. Some of the core developers responding you can use any shell you like will never solve this problem. I hope I can so the argments between UI people and coders here can go to bed forever.

Lucractius
Posts: 47
Joined: Fri Oct 21, 2005 4:27 am

Post by Lucractius » Fri Nov 11, 2005 7:13 pm

as for definitions ill throw an XML style one down off the top of my head right now. (its late and im very busy this week so dint have time to think of more)

<ItemBlock position=x,y [insert other groupable properties here]>
...
<widget_thing relative position=x,y [properties]>
...
</widget_thing>
<widget_thing2 relative position=x,y [properties]>
...
</widget_thing2>
</ItemBlock>

the ItemBlock represents a group of items that get moved together, colours change together, etc. and holds them likt that.

oiaohm
Posts: 1322
Joined: Sun Dec 12, 2004 8:40 am

Post by oiaohm » Sat Nov 12, 2005 2:03 am

Mixed Format.
[icons]
progamname=icon.svg
....
[cursers]
wait=image
....
[Sound]
startup=start.wav
....
[Start menu]
Xaml style resource or Microsoft dialog resource format.

This is the problem there are alot of options. Working out the best is not simple. Pure XML does not have to be the answer. I am not prepaired to try to work all this out untill we know how much is required at this point.

Lucractius
Posts: 47
Joined: Fri Oct 21, 2005 4:27 am

Post by Lucractius » Sat Nov 12, 2005 4:34 am

well then, id say working on defining those requirements would be the way.

scaleable design
  • must handle short small lists easily without bloat just as well as handling large complex desktops
    simple design for fast parsing
    crashproofing! every x minutes or whatever, the config file is updated to reflect the current desktop. icon positions, window locations, etc.
    design must handle the addition of user created custom definitions for whatever reasons they come up with, handling the parts it can correctly and knowing how to ignore the others.
needed elements
  • icons [screen location, command attached. these 2 are the very least that an icon needs, more could be added]
    wallpaper/pictures (screen loc, size?.)
    app windows, programs can be added to the design so depending on the destop layout, certain programs may be opened, (should take place last for speed efficiency reasons) with defined window sizes and other properties.
    ReactOS menu & button, need to have it its got to be an element.
    Quick Launch, same.
    Task Bar, again need it.
    System Tray, need this too.
    Clock, no matter what other clock i have open, somehow the system tray corner always feels weird without a clock there thats always working properly.
    The 5 elements above should by default be defined as a group. moving together, having the same colour schemes/skinning applied to them, and working like a traditional "taskbar", best gauge, does anyone notice when they look that its any different? if not, then thats got it right. (but remember, as separate elements they CAN be ungrouped and played round with if the user wants to :) )
now... as for the nitty grity details. I just realised that by defining things in an tree we get a way to handle themeing of many things at once. there are global theme properties at the top of the item tree, border colours, fonts, etc. As you go down, groups of items can override this with their own group settings IF they want to, otherwise those are given the system ones, and isnide each group individual subgroups or items can override the group settings again.

whys that interesting? level of detail slider, slow system can ignore per item theming to reduce system load during startup to speed up the proccess.

and id also make the case that items get a property added to them, something like an "importance flag" that determins how much the system should care about keeping them there. based on a ruleset of some kind, items of "low" importance can be disgarded/unloaded/closed by the desktop to save/increase resources for various tasks.

Ive got fancy desktop stuff myself but when i play games, i cant even see them. why should the system wast resources on these? with an average to slightly above average "importance flag" setting they would be on my desktop while i worked, but when i load up a game, the in use system resources start to climb, and the desktop closes or fresses or whatever, the unimportant things.[/list]

oiaohm
Posts: 1322
Joined: Sun Dec 12, 2004 8:40 am

Post by oiaohm » Sat Nov 12, 2005 6:04 am

crashproofing! every x minutes or whatever, the config file is updated to reflect the current desktop. icon positions, window locations, etc.
Must not include application windows. Crashproof has to be done very carefully. Loss of a bit of desktop information is better than a loop setup. Ie the storage of crash prevention leading to a login reboot cycle.

Also crashproofing I don't really recommend going to far. If running like drbl ie no harddrive this can causes a lot of load. It mush be able to be turned off. Altering the master theme file must take user intervention. First hand experences with X11 crash proofing kinda scares me off it. Evey 1 minute recorded every open applications in case of crash restored desktop perfectly back. Problem 1 sec to application logining me out and the crash proofing recorded it. Log in straight out again.

Dynamic looks like a good idea until you do a speed assesment. This has to be user controlled. Or you can endup with confused desktop. Shrink game disk top reload. Drive access load problems. This is the last feature if even created just due to the problems of pulling it off.

When you go full screen the desktop does freese. Reason for the lag when fliching from DirectX games back to desktop be as long as it is.

This is heading in the right direction. My X11 experences showed me alot of scarry things that could go wrong. Ie more desktops more create ways to screw a user up.
Last edited by oiaohm on Fri Nov 25, 2005 1:29 am, edited 1 time in total.

oiaohm
Posts: 1322
Joined: Sun Dec 12, 2004 8:40 am

Post by oiaohm » Sat Nov 12, 2005 6:06 am

The guest post above here is me. Ok who turned guest on be careful everyone. Oiaohm (the guest was the post before this one it been transfered to my name don't look for it its not there anymore)
Last edited by oiaohm on Fri Nov 25, 2005 1:34 am, edited 1 time in total.

GvG
Posts: 499
Joined: Mon Nov 22, 2004 10:50 pm
Location: The Netherlands

Post by GvG » Sat Nov 12, 2005 10:51 am

oiaohm wrote:The guest post above here is me. Ok who turned guest on be careful everyone. Oiaohm
I've disabled guest posting, thanks for the pointer.

Lucractius
Posts: 47
Joined: Fri Oct 21, 2005 4:27 am

Post by Lucractius » Thu Nov 24, 2005 8:16 pm

Absolutley oiaohm.

The #1 thing is always control. the control that lets you say NO to the extras. ( I just cant say this enough lol )

Crashproofing done right can be an utter godsend. before i switched to firefox i had an IE based browser called SlimBrowser from Flashpeak software. it included crash protection that stored the information regarding the open tabs and when the browser reopened, it promped the user to decide wether to open the tabs that were there when it crashed or closed or not to. Again the key is control :)

If an application isnt able to handle crashproofing internaly then i wouldnt push them any further into a "crashproofing" system than the system being aware that App $foo was open at position X,Y with window properties $bar[]. the internal application data, like you said, is probably better off lost in the event of a program crash.

Dynamic is a powerful possibility, but definatly should be "implemented" last, BUT should not be considered last (IMHO). If it is always considered last then its likely to succumb to developer complacency and get marginalised out of the designs, It may not be feasable to implement it. But it should remain part of the design. Since I know this kind of thing is in Vista for gaming, it shouldnt be ignored in reactOS.

One more thing that just sprung to mind. Eclipse. Much maligned as it can be, the Views functionality is bliss. I have a dual screen system at home, and eclipse installed in a portable drive to carry the development enviroment with me whereever i am :), When im not working on my dual screen, i can simply change veiw and eclipse adjusts all the layouts to the saved View. Now instead of internal view of an IDE, replace that with the Screen setup for a set of desktop apps, and their startup parameters and so on. Essentialy it creates a system similar to virtual desktops, but the nature of having user defined "screens" containing sets of applications and their positions that they can just switch between as easily as a linux user can Switch Virtual Terminals. Is quite interesting :) Especialy if there are things like separate keyboard mouse focus. browse by mouse, type notes in transparent notepad prog that maintains foreground focus and keyboard while using mouse on browser. :)

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests