-
 KDE-Apps.org Applications for the KDE-Desktop 
 GTK-Apps.org Applications using the GTK Toolkit 
 GnomeFiles.org Applications for GNOME 
 MeeGo-Central.org Applications for MeeGo 
 CLI-Apps.org Command Line Applications 
 Qt-Apps.org Free Qt Applications 
 Qt-Prop.org Proprietary Qt Applications 
 Maemo-Apps.org Applications for the Maemo Plattform 
 Java-Apps.org Free Java Applications 
 eyeOS-Apps.org Free eyeOS Applications 
 Wine-Apps.org Wine Applications 
 Server-Apps.org Server Applications 
 apps.ownCloud.com ownCloud Applications 
--
-
 KDE-Look.org Artwork for the KDE-Desktop 
 GNOME-Look.org Artwork for the GNOME-Desktop 
 Xfce-Look.org Artwork for the Xfce-Desktop 
 Box-Look.org Artwork for your Windowmanager 
 E17-Stuff.org Artwork for Enlightenment 
 Beryl-Themes.org Artwork for the Beryl Windowmanager 
 Compiz-Themes.org Artwork for the Compiz Windowmanager 
 EDE-Look.org Themes for your EDE Desktop 
--
-
 Debian-Art.org Stuff for Debian 
 Gentoo-Art.org Artwork for Gentoo Linux 
 SUSE-Art.org Artwork for openSUSE 
 Ubuntu-Art.org Artwork for Ubuntu 
 Kubuntu-Art.org Artwork for Kubuntu 
 LinuxMint-Art.org Artwork for Linux Mint 
 Frugalware-Art.org Artwork for Frugalware Linux 
 Arch-Stuff.org Artwork and Stuff for Arch Linux 
 Fedora-Art.org Artwork for Fedora Linux 
 Mandriva-Art.org Artwork for Mandriva Linux 
--
-
 KDE-Files.org Files for KDE Applications 
 OpenTemplate.org Documents for OpenOffice.org
 GIMPStuff.org Files for GIMP
 InkscapeStuff.org Files for Inkscape
 ScribusStuff.org Files for Scribus
 BlenderStuff.org Textures and Objects for Blender
 VLC-Addons.org Themes and Extensions for VLC
--
-
 KDE-Help.org Support for your KDE Desktop 
 GNOME-Help.org Support for your GNOME Desktop 
 Xfce-Help.org Support for your Xfce Desktop 
--
openDesktop.orgopenDesktop.org:   Applications   Artwork   Linux Distributions   Documents    Linux42.org    OpenSkillz.com   
Xfce-Look.org - Eyecandy for your Xfce-Desktop
Xfce-Look.orgXfce-Look.org

 Apr 25 2024  
 Not logged in  
Xfce-Look.org
 Home    Add Artwork   Forum   Groups   Knowledge   Events   Jobs   Users   Register   Login-

-
- Group .- Group members (31) . 

FluiDE (New Computer Interfaces Discussion)


other
user333user333
Description:

https://sourceforge.net/p/fluide


http://groups.google.com/group/fluide/
http://code.google.com/p/fluide/
http://code.google.com/p/fluide-attach/


This group is to discuss a new interface for Linux, and hopefully make one, based on top of Gnome or another desktop environment.

The main goal of this interface will be to create an extremely natural and "out of your way" shell. All aspects of traditional interfaces will be examined to see if they are the best implementation for today. Reinventing the wheel may not be best in all cases, but what about when the wheel becomes obsolete? For example, the traditional menu first appeared around the 1980s! Things have changed since then. Of course, ideas on how to do it other ways will be subject to the same rules. Just because it is different doesn't mean it is better.

What got me started thinking this way is when I saw this mock-up by Martin Gimpl:

http://personal.inet.fi/koti/mgimpl/stripes/

Some of the ideas are very interesting! Also, with all the new interfaces coming out (Gnome3, Unity, Windows 8) it seemed like this would be the perfect time to try to start a new project.

NOTE: Although I have the group set so I have to moderate who can join, I want everyone who wants to join to do so! I only have that as a precaution against spam.

Homepage:homepage
Members:31
Comments:204
Created:Jul 13 2011
Changed:Apr 27 2012
Readability:readable for everybody
Membership:new members need admin approval

Invite people to join
Join group
Activate message notification



goto page: prev   1  2  3  4  5  6  7 

-

 Ideas and later programming skills

 
 by novomente on: Sep 11 2011  
Score 50%
novomentenovomente
Home

If you are looking new ideas on how to use computers or applications, I could be useful in this project. And I'm happy that somebody started this activity to think seriously about new Desktop Environment in these pioneering times (Gnome Shell, Windows 8, Android etc.).

Although my graphical skills are poor and my aestetical feeling is only enough to make nice web pages or easy graphics, so I can't make beautifull design of DE or UI, more I am able to bring new ideas from a view of functionality, logic, new features and how to use (how easy and how quick and efectively use) applications or computers or other devices.

Many times I thought about how to newly use operating system and applications. Due to my only basic and sometimes little advanced programming skills, most of ideas was forgotten in times. But new ideas still come up. From the next year my programming skills should be better as I start studying software engineering on university. Then maybe I will be enough experienced to offers some programming skills.

That is what should be said about me till now.

To add some comment in this group I want to say that I realy like the Martin Gimp's Stripes. I know that a lot of people thought about searchable menus (including me) and usage of menus (non Ribbon classical menus in Microsoft Offices offered the usage favorites) and also vertical menus in NeXT OS is also very old, but to design menus like this whith these features it's just a beautiful solution (for mouse and touchscreens).

Althoug I cannot still imagine how menus like MGimp's should well work in big full feature rich applications as Adobe or 3D design applications etc. But it could be one of the nice tasks in this group. Even for me it could be a start somewhere.


Reply to this

-
.

 Re: Ideas and later programming skills

 
 by novomente on: Sep 11 2011  
Score 50%
novomentenovomente
Home

Oh sorry Martin Gimp is Martin Gimpl of course. I just work with GIMP application as often (every day) as its name is in my mind first to similar names.

I appologize.


Reply to this

-

 Re: Ideas and later programming skills

 
 by MasKalamDug on: Sep 12 2011  
Score 50%
MasKalamDugMasKalamDug

I am suspicious of aesthetics and talk about beauty. Not that I oppose them but it is just that, it seems to me, tastes differ wildly and fashions change frequently.

Thus, again it seems to me, we should favor customization over aesthetics. It would be naive to imagine every user of a customizable interface will use it in ways that look good to us.

I tend to punt on this issue and claim I am following the Bauhaus design principle - function should determine form. Hence we should provide the means to supply "beauty" but not ourselves attempt to define it.

I am displeased by most websites I visit - including this one - because they strike me as cluttered and much too busy. And it is not clear how a website can look good and simultaneously show ads designed by other people

On my own website I use only simple basic HTML and nobody has ever offered, nor do I expect them to, pay for an ad.

Bottom line - I would design to maximize customizability and let the aesthetic chips fall where they may. Of course, if it ever comes as far as actually shipping I would include some good examples for people to follow - and make one of them the default.


Reply to this

-
.

 Re: Re: Ideas and later programming skills

 
 by user333 on: Sep 12 2011  
Score 50%
user333user333

I tend to think of it this way: an average user is not a designer or an artist. We design for them, and then they choose what they like best. For example, we might have several color schemes available.

One example of this idea would be in word processing. A user will make an awful looking document if they just adjust fonts and sizes manually to make headers, footers, and other parts of the document. But, if they use the preset styles, they can create attractive documents easily. Then they can change the preset if they want to, which still styles their document consistently.

So if we allow advanced users to tweak the interface, I would agree with doing that. I would also allow the user to pick different presets that represent a wide range of personal tastes. One size will never fit all. But leave advanced stuff for designers. This will keep it professional and clean-looking.

By the way, I'm not trying to put you down at all. One of the main things I decided when I started this group is that EVERYTHING has to be examined very carefully. I'm hoping more people will speak up on this issue so we can make a better decision.

Here is the single most important thing you can ever read:
http://contenderministries.org/romanroad.php
If you agree, put this in your signature too ;)
Reply to this

-

 Re: Re: Re: Ideas and later programming skills

 
 by MasKalamDug on: Sep 12 2011  
Score 50%
MasKalamDugMasKalamDug

Don't worry. I don't feel attacked.

You are more sanguine at OUR ability to get things right than I am. I know my design ideas are not those of the web site and GUI designers whose work I keep looking at.

But practically speaking, we are not very far apart. I think any actually shipping software must be accompanied by examples of customization. The average user can be expected to never change the default example. Very few users will opt for complete customization - but they are the ones we want to reach out to.

In application design especially, it is important to remember - I am not an expert on how this will be used.

I can see a way people who are interested deeply in interface design can be essential for success.
Example in point -tooltips. They fit awkwardly in every design approach I have seen and I might, in a fit of self-confidence, design a GUI methodology that did not include them. Interface designers would, I believe, quickly tell me that that was a mistake and set me on the right path.

That is, we must provider everything the designers say they need.

But we can push back. One point I want to push back on is menus. I think they have become a bad idea. The intellectual content of the menus must be supplied somehow. But not in the traditional way.


Reply to this

-
.

 Re: Re: Re: Re: Ideas and later programming skills

 
 by user333 on: Sep 12 2011  
Score 50%
user333user333

Yes, I think I would agree then :) I guess I just mis-understood the way you said it at first.

Expanding on your tool-tip example a little more, (for the sake of this example I'm assuming we don't want to use traditional tool-tips), I would give the same functionality of tool-tips, but in a different way. We could take the tool-tip from the program and put the text in a special place on the desktop. A similar thing could be done with menus. A global menu could be used, and then display the controls using an alternative approach. This would keep application developers happy because they don't have to change anything. Of course, we can give them better, more integrated options for those who want to use them.

Here is the single most important thing you can ever read:
http://contenderministries.org/romanroad.php
If you agree, put this in your signature too ;)
Reply to this

-

 Re: Ideas and later programming skills

 
 by user333 on: Sep 12 2011  
Score 50%
user333user333

Yes, we need lots of new ideas :)

That would be great if you could help with coding later on, too!

Here is the single most important thing you can ever read:
http://contenderministries.org/romanroad.php
If you agree, put this in your signature too ;)
Reply to this

-

 Re: Re: Ideas and later programming skills

 
 by user333 on: Sep 13 2011  
Score 50%
user333user333

I came up with this idea on how panels could work:
http://opendesktop.org/content/show.php?content=145206

Let me know what you think!

I tried to post this before but it didn't show up, so I'm sorry if I double posted. It also kept going other places than I meant it to, so I'm replying to this message. I think the comment system is broken or something.

Here is the single most important thing you can ever read:
http://contenderministries.org/romanroad.php
If you agree, put this in your signature too ;)
Reply to this

-

 Re: Re: Re: Ideas and later programming skills

 
 by Padster on: Sep 13 2011  
Score 50%
PadsterPadster
editor
Home

Looks fine to me.
Commented there :)

101010
Reply to this

-

 Re: Re: Re: Ideas and later programming skills

 
 by novomente on: Oct 21 2011  
Score 50%
novomentenovomente
Home

Hi guys. It is more than a month from time this group had a comment. Since that I started the university study. But I didn't know how time consuming it was, so I wouldn't have time to devote it to other things especially to this group. But today I found it.

First let me apologize for something. I read the comments here again including mine and found out my missusing of english. Studying this language, due to university, showed me that I used a word "just" in a wrong way. And my comment here on Martin Gimpl's Stripes sounds wrong. The missusage is exactly around the mentioned word "just". So instead of "it's just a beautiful solution" should be said "what a beautiful solution" or "such a beautiful solution" or simply "it's a beautiful solution" or something like that. It's a shame that my poor english is hard to use on what I want to express and could sound very differently. So let me apologize to Martin Gimpl and all of you guys.

Your (Mike Gray) mockups are cool. Searching programs from file manager is perfect. And you have 2 areas to show searched things - the side pane area and main area. So it allows to use side pane as M.Gimpl's menu and main area as a icon views etc. As you can see on similar figures to yours here:

http://novomente-activities.blogspot.com/2011/10/mike-grays-file-manager-usage.html


The idea with Dynamic Panel System is also interesting. The menu on the left could be used for example as shown here:

http://novomente-activities.blogspot.com/2011/10/mike-grays-dynamic-panel-system-usage.html

It's a Windows 7 and vertical menu clone.


These are not some new ideas but only modifications. To bring new ideas on DE usage I want to add 2 links to push the imagination (or how to say that). First is multitouch screen (I think this guy is working for Microsoft, but I'm not sure):

http://www.youtube.com/watch?v=tr_RgOTum3M&feature=related

the other is a sketch device for 3D and show the nice possibilities by using a stylus on screen:

http://www.youtube.com/watch?v=5Hd2clwURlQ&feature=related


Reply to this

-
.

 Re: Re: Re: Re: Ideas and later programming skills

 
 by user333 on: Oct 22 2011  
Score 50%
user333user333

Don't worry about your English. I understood what you said fine ;)

Your ideas look really cool :) I like how the selected file gets a contextual menu in the sidebar. That eliminates the need for right-clicking, making things easier for users.

The mockup you made about the dynamic panel system looks really interesting. It gave me some more ideas that I'll try to post later.

I haven't posted much here either, because I have been learning about X and how it works. I think HTML may be a possible way to draw the interface, but I don't have the skills in gtk, gdk, and X in order to create anything. I did, however, manage to make a webkit app that stayed below all other apps. Then I would launch a window manger, and have a very non-functioning interface. Even though it didn't actually work, it does prove it's possible to create the whole project in webkit. Even if we don't, it would be idea to make working tests of ideas.

Another reason I haven't posted is because I have had a horrible time trying to post to this group. My comments hardly ever show up :( Also, I've been busy re-designing my terribly ugly website, so that takes up a lot of my free time too.

Here is the single most important thing you can ever read:
http://contenderministries.org/romanroad.php
If you agree, put this in your signature too ;)
Reply to this

-

 Re: Re: Re: Re: Re: Ideas and later programming sk

 
 by novomente on: Oct 22 2011  
Score 50%
novomentenovomente
Home

I know the problem with non working "Add comment" link. Exactly there are 2 same "Add comment" links there. One is working the other does not. I don't remember which one of the two is working. So I solve this problem by writing a comment to Gedit (Gnome Text Editor) and then try one link. If the posting with the link doesn't show a comment in group then I try the other one. The other one is 100% working.

Writing a comment to Gedit (or whatever local text editor) has one more advantage. When my computer turns off due to possible electricity problems (blackouts or similarities) the comment still remains on harddisk because I save it. After successful posting I just delete it or wipe it.


Reply to this

-

 Look and Feel

 
 by randallovelace on: Oct 22 2011  
Score 50%
randallovelacerandallovela ce
Self Employed - Computer Repairs

Hi everyone - and thank you for allowing me to join this group.

I am more 'end user' than designer, but I know a lot of people and the typical thing I hear is they like/don't like the 'look and feel' of a desktop OS. What's worse is I agree. Gnome/Unity - I don't like having to search for an app that under the old Gnome 2 is just a couple of clicks away - I don't like junk taking up my desktop space. And I don't have any Icons on my desktop (that's what the menu's are for thank you very much). One think I do like is from Enlightenment and that's having all of the menus on a mouse click, allowing you to get to any application with just a click (as long as your mouse is on the background of the desktop).

I also prefer only one 'tool' bar - and I like to be able to put it where I want it (top/side/bottom), I like being to able to add/remove apps from the bar (full customization).

I like themes - I like being able to edit/modify themes (I use one now that had dark gray and orange as it's main colors and I've changed the orange to blue).

I like 'smooth' yet simple looks to my windows and to my menus... I'm not trying to look like Windows 3.1 and also not trying to look like Windows XP/Vista either. People should look at a computer screen and be able to know that simple task are still simple (like opening a browser or an office program).

These are just some end user thoughts.

I'll come with more as I see more 'development on the look' of this new desktop.

Randal Lovelace

Randal Lovelace
Reply to this

-
.

 Re: Look and Feel

 
 by user333 on: Oct 22 2011  
Score 50%
user333user333

Thanks for joining =) One idea I have (I'm speaking for myself here, not the entire project) is to use a "dynamic panel system" (You can see the above post for a link). This would make it easy for any one to have the panel where they want, without changing any settings.

If you are concerned about the appearance of this project, I wouldn't worry about that too much ;) Mostly we are trying to create new interface designs, not new themes. Also, unless we are creating our own toolkit, we don't have much say about how theming works, so expect to use the same kde and gnome themes that you like ;)

About the Unity programs menu, I find the Unity menu horrible. Although I like the Gnome menu in some ways, I would agree that Gnome 3 could have done things better as far as the layout. However, I don't think standard menus are the way to go. There MUST be a better way. I do find it less frustrating than other methods, but just locating the program in that long list takes me forever.

Here is the single most important thing you can ever read:
http://contenderministries.org/romanroad.php
If you agree, put this in your signature too ;)
Reply to this

-

 Re: Re: Look and Feel

 
 by randallovelace on: Oct 22 2011  
Score 50%
randallovelacerandallovela ce
Self Employed - Computer Repairs

I did look at the various links, mock ups and read through the comments to date on this. I like some of what I see, and other stuff not so much. I know that the back end to make things work is WAY beyond my skills, but as the end user type person (I also do 3D and 2D art using Blender and Gimp).

If you were able to combine all of the back end function from Gnome 2, with all of the look of Unity, and the capability of Enlightenment, then I think it would be a 'win'.

I think with most modern desktop/laptops that smooth looks, ease of use, and customization are going to be the key for future development of the desktop environment.

I think that the new desktop needs to work more like a cell phone 'app' system - as that is used more now than even Windows desktops... ie don't retrain people to use computers - just allow them to do what they know already.

Consider looking at the 'look and feel' of the 10" Tablet PC - the Samsung Galaxy in particular.

The Android OS is extremely light back end, but still power full enough to do everything needed.

Maybe, part of what I'm saying is that the OS environment has become a bit bloated to do the same things that much lighter weight OS have been doing on phones for a few years now, and really they aren't doing that much more than what Windows 3.1 was doing back in the 80's, they communicate between user and machine to follow instructions. Admittedly some of those instructions are more complex now, but my thinking is that most of it is still very basic.

Simple, configurable, usable.

Randal Lovelace
Reply to this

-

 Re: Re: Re: Look and Feel

 
 by MasKalamDug on: Oct 25 2011  
Score 50%
MasKalamDugMasKalamDug

I haven't been posting lately but I have been thinking. Here is where I am now:

Define an application as an XML type script which specifies a packing. Executing an application means using the script to populate a window (rectangular piece of (or all of) the screen) and then calling (equals send a message to) the application's designated entry point.

The top level interface is just another application in this sense. The interface layout is the script and it is available to be rewritten (customized) by the user in any way desired.

The elements in the script are boxes of various kinds. Everybody should be familiar with vboxes and hboxes. The attributes of a box should include styling more or less equivalent to CSS styling. If the element is a leaf (box in my jargon) and not a container it has the identifier of an object class an another attribute. When the script is executed the object class is asked for an instance object. Then that instance object is asked for the size of its icon (the picture that fronts for it in the GUI) and that determines the size of screen real estate set aside for that element. The actual icon pictures must be drawn in a second pass through the script because the exact screen locations are only known after the packing is complete.

Keyboard access to an element is another element attribute.

A major consideration here is the handling on add-ins. An add-in is installed by adding its object class and keyboard access to the script. That's all. An add-in, like a utility, may not be used directly. So I would add hidden elements to the script to bring this kind of object into the application.

One kind of hidden element would be a menu element. A menu is both a leaf and a container. The contents of the mbox are hidden until the mbox icon is clicked and they disappear when no longer in active play. But while they are visible they behave like any other icon.

The operating system per se handles the applications and the peripherals but unloads its messages to some application as soon as the proper application can be determined and loaded.

Note that the GUI is no longer part of the operating system except in the window manager sense. I am dubious about almost all of what I called window management (by which I mean resizing and relocating). This is a point that has never been satisfactorily resolved - is there any valid reason that a user would want to arbitrarily resize and/or move a window? Screen splitting is not included in this comment. Windows 1 was tiled (as I would have it) but Microsoft went to arbitrary move/resize with Windows 2. We all know that Windows strongly influenced X. Maybe Microsoft was wrong. Wouldn't be the first time.


Reply to this

-
.

 Re: Re: Re: Re: Look and Feel

 
 by novomente on: Oct 26 2011  
Score 50%
novomentenovomente
Home

I think I don't understand it clearly as I'm not experienced in programming yet. But let me tell you what I had in my mind, when I started talking to you in this or another group. My goal in creation applications is this:

Split application in 2 parts.

One part is what application can do, it's features and functionality (means what user is using the application for). This part does not include GUI or any User Interface. This part is what user can't see and what happens (when running application) only in RAM and Processor and HDDs etc. but not on Monitor or other displaying device.

The other part is exactly a UI (GUI or another User Interface). It is what user can see on Monitor or another device and with what it interacts. It is the layer between user and the first part - application functionality.

In programmers view the First part is a code and libraries for functionality unseen by user and is programmed by coders. The Second part is a code and libraries for UI and then UI itself. Code and libraries are programmed by UI coders and can be standardized through one or more applications (even Operation System). The UI itself is designed by UI designer.

Thus application's functionality is a work of coding (algorithms, math etc.). UI libraries and code is work of coding (algorithms, math etc.) and UI design is a work for UI designers (logic of usage and visual design beauty).

In your comment view.
- Functionality - is a code of an application (in C, C++, JAVA etc.)
- UI code & libraries - defining functionality and displaying of boxes, leaves, menus etc, interaction with mouse, touchscreen etc.
- UI design - is a script which defines where to display boxes, leaves, menus, what menus includes, which icons, colors it has etc.

Splitting these parts help in application development. Coders and UI designers can concentrate on their work, application functionality does not too much change and changes goes to UI (the application can be used in PC or tablet or Smart Phone etc.) Moreover it allows to create different UI designs of one application (for ex. the OpenOffice can change its UI either to it's own UI or can easily be changed to MicrosoftOffice or moreover to very different UI that handles the interaction of what application can do) - these are UI profiles. It allows to add new functionality with add-ins and easily implement them as full part of application (the code of an add-in is not wrapped (or can be) in application's code but is a full part of application's code, change UI design to add new functionality features to user is then easy). And so at very beginning you can have simple application but with add-ins user can change it to a full featured rich application with different UI profiles and thus with different usage - let's say that you can make OpenOffice to edit Macromedia Flash and so on).

That is my idea. And it's where I tried to target the talk in http://gnome-look.org/groups/?id=582 group. Seems that you solved the techniques. If this comment inspire you to make better programming techniques, I'll be happy.


note: User may want to resize a window when it wants to simulate small screen in a development environment. To see how application looks in small screens or in small windows.


Reply to this

-

 Re: Re: Re: Re: Re: Look and Feel

 
 by user333 on: Oct 28 2011  
Score 50%
user333user333

I like this idea :) It would prevent "finger painting" the UI, similar to the idea of LaTeX. You simply write the content, and let someone else handle the look&feel. Of course, this sort of thing couldn't be applied to existing applications.

Here is the single most important thing you can ever read:
http://contenderministries.org/romanroad.php
If you agree, put this in your signature too ;)
Reply to this

-
.

 Re: Re: Re: Re: Re: Re: Look and Feel

 
 by novomente on: Oct 28 2011  
Score 50%
novomentenovomente
Home

Oh I forgot. The UI Design in the paragraph under the text "In your comment view." in my previous comment should say more...

- UI Design - consists of 2 file types. One type describes the layout of UI (i.e. what menus, buttons, boxes, content windows should be displayed, where to display them and maybe when to display them - similarity to HTML, CSS and JavaScript in defining the layout of whole UI) and is a UI profile. The other file type describes exactly the look&feel (i.e. colors, borders, fonts, icons, pictures, animations - similarity to CSS in definnig the look&feel) and is a theme.

The First file describes the layout of UI (change LibreOffice to MicrosoftOffice). The second file describes the look&feel of UI (change theme - Clearlooks, Crux, High Contrast, MacLike, KDElike, Se7en etc.). Both files are chooseable and/or changeable by user (it depends how the application developer decide).

First file type (describing the layout) interoperate with "UI code & libraries" part (and can be JavaScript, Flash ActionScript, or whatever language). The second file type (describing look&feel) is only a file which has no interoperability (XML, CSS or whatever).



-

 Re: Re: Re: Re: Re: Look and Feel

 
 by MasKalamDug on: Oct 28 2011  
Score 50%
MasKalamDugMasKalamDug

Re splitting applications into two parts: I have the same notion you have on this matter. But it is not always an obvious thing to do. Consider a text editor. The text itself is quite simple and can be handled by a few methods (the minimum is three - a delete, an insert and a move) but the presentation of the text in the GUI has all kinds of complications. I think splitting the presentation into two parts - the GUI and the GUI-handling code - is the best way to go. So I have split the application into three levels. Obviously we should generalize and allow an arbitrary number of levels - leaving the GUI on the top of the pile.

Re the UI design: You are visualizing a rather complex set of UI capabilities so, as I mentioned above, you probably need to split the UI into the actual presentation and its supporting code. Essentially this interface is what a "language" like HTML5 is doing. The application in a web document has a trivial backend - the HTML5 document. I don't think HTML5 is the definitive tool for a web presentations but it is the current best (that I know of). This suggests that the application back end should write an HTML5 document and send it to the GUI.

That would probably work. It would certainly simplify this discussion out of existence - or into a discussion of a new HTML to replace HTML5. The work of trying to get application writers to conform with HTML5 (or whatever) is, I assume, nothing any of us wants to take on. Note that the back end still must write the document. The GUI designer works with, essentially, the CSS part of the presentation.

A real life application would push a dynamically changing document at the HTML. But this should be handleable.

The fact that I have merged the operating system and the web browser should surprise no one.

Re resizing windows: I assume that each time an application runs it is given the size it is to run in. In that sense resizing makes sense. It is size changes during processing I was dubious about. Windows 3 had icons for minimized programs that functioned fully as windows albeit tiny. This has not proven to be a feature people want.


Reply to this

-

 Re: Re: Re: Re: Re: Re: Look and Feel

 
 by MasKalamDug on: Oct 28 2011  
Score 50%
MasKalamDugMasKalamDug

The example of the text editor is still instructive.

I would formulate the presentation in such a way that the actual text display was a dynamically changing picture written and rewritten by what I called the middle layer in another post. The GUI itself is the other controls. I am using gedit to write this and the GUI seems to consist of four lines at the top, a status bar at the bottom and a one pixel border around the big picture where this text is appearing as I type it.

But the text proper neither knows nor cares what part of it is displayed in the window or where the line breaks are. And one of the navigation things I can do is move the caret up or down. And where the caret goes depends on the width of the window - a datum the text knows nothing about. The great mass of the coding goes into the middle layer. We need to be clear about the architecture before we do anything else.

Speaking of LaTex in the original TeX Knuth solved all these problems by not having a GUI interface. You had to run your TeX document through a printer to see if you liked the result. We could use an updated version of this in our text editor by letting it function at input time at the level of gedit and then running it through display logic. About like Sea Monkey. I seem to have re-invented the HTML editor.

If one still takes printed media seriously there is a conflict between the print design and the GUI design. Just look at Google Books if you wonder what I mean.



-

 Goals

 
 by user333 on: Oct 29 2011  
Score 50%
user333user333

It seems that we have never actually decided on our main goals, so now is a great time to decide ;) We need to come to an agreement before we go much farther, so please comment!

What is our overall goal? To become a popular DE, or be an example of an ideal interface? Or both?

I doubt that unless the project becomes as main-stream as Gnome or KDE, no application developer will change a program to be compatible with us. However, if we have ideal goals in place, but delay them so existing programs will still work, then later on perhaps we would have enough influence to cause application developers to use our methods. Or, possibly an existing DE would like our project and use some of it's ideas.

I (I'm speaking for myself here) think we should limit ourselves to only creating a "shell" but not our own development libraries, similar in some ways to Unity. While we could try to make an entirely different system from the start, people would not accept the changes, so we introduce them in stages. We can use some "hacks" such as a global menu that uses our design, but still use the standard GTK and QT. Then, if we get a good amount of acceptance, we can try introducing better ways of writing programs.

Here is the single most important thing you can ever read:
http://contenderministries.org/romanroad.php
If you agree, put this in your signature too ;)
Reply to this

-

 Re: Goals

 
 by MasKalamDug on: Oct 30 2011  
Score 50%
MasKalamDugMasKalamDug

Everybody who posts here seems to agree that what we are after is, I think, what you called a shell. We want a system where the interface designer (and by implcation a knowlegedge user doing customization) can work as separated as possible but in parallel with the application programmer(s). This is going to cause many difficulties to most existing applications. The usual way to handle this is to build a wrapper around the legacy code that makes it feel like code in the new style.

The only hope I can muster for wrapping code based on X11 is to simulated the server (I may have that backwards as usual - I mean what was once called the terminal). This might actually work. But before we can even discuss it we need to know what the wrapper looks like. So for the moment we should ignore the existing applications problem.

Personally I couldn't care less whether anybody uses our new interface design. My goals are to formulate it and then drop it out there into the public domain (GNU license is public enough - I just want nobody claiming it as THEiR property). If something good is available for free somebody will run with it. If our work isn't good enough - so be it.

So now I am studying how the internal interface between the front end (the user interface and its controls) and the back end (the application code) might work. I am trying to define a re-implementation of gedit as a test case. My assumption is that the front end is scripted and the back end compiled. The script executor will do approximately what a web browser does - the script itself resembles HTML. But what else happens is still a mystery to me.


Reply to this

-
.

 Re: Re: Goals

 
 by novomente on: Oct 30 2011  
Score 50%
novomentenovomente
Home

Yesterday I woke up at 4 o'clock in the morning and whole day I was thinking about it. Reading a lot about compilation, linking, memory management etc. I got many many many crazy and awesome ideas. To hurry up to add a comment (for the reason the communication at weekend will continue) I add something today. I wanted to add it yesterday evening, but I was so tired as I decided to leave this task for today. So answering...

Exactly. As you say. My understanding is the same. There will be more parts of application structure in a pile because the applications created for computers are very different (small Text pad, rich Office, Flash player, 3D animator etc.) and will be created in a very different ways (with different parts and layers in a pile). I was thinking to leave this decision as a freedom for application developers and a matter to discuss here.

Yes the middle part is needed. I called it "UI code" while "Libraries" represented for example the GTK or Qt etc. "UI code" does the "presentation" as you say - it is the presentation part of the "display logic" you said speaking of LaTeX. My naming is not correct as the "UI code" in a programmers point of view can be created as a code and/or libraries. Same is with what I called the "libraries" which can also be a code in programmers point of view. So I'll use your naming - the "middle part" and "presentation" what together (with something more) can be a "display logic".


Quote:
This suggests that the application back end should write an HTML5 document and send it to the GUI


At the beginning of thinking about the idea I imagined that the back end (main part) wouldn't deal with UI at all. It means it will concentrate on main goal it is doing - i.e. text editor will work with text (insert, delete, write, format it etc.), image manipulation program will work with image (draw lines, shapes, gradients, lighten, darken, use effects etc.), the Flash player will render the swf file, the music composer will add notes, breaks, instruments etc.

Of course there must be some communication between the back end (main part) and middle part. I'm not sure what kind of communication it will be. I was thinking of not standardize this communication. It means that the communication form is what application developers will decide. Or we can still bring better solution.

Yesterday I was thinking of using something like module programming technique. The back end (main part) and middle part will have some interfaces to communicate each other. Previously I thought the shared memory was the point of interaction between the parts. Lets say for example the main part (back end) will change something in a shared memory (indicators or whatever). The middle part will detect the change and decide whether it must to redraw something in GUI. I was thinking about that the main part will be something like a little operating system allowing multi threading of parts and handle memory management and execution/time management. Still it is the thing to discuss.

Again I don't mean to standardize the technique because it could be problematic for some kind of application. We could offer some new programming techniques and offer to follow them. But the final decision is made by the application developers.


I'm not sure about the solution the GUI-part will render the GUI interface. Whether it use the HTML-like, CSS-like, script-like technology. Honestly it could be nice if it uses it because the GUI-part developers and GUI designers could work with technologies commonly known (they need not to learn anything new). But will it be the perfect solution? I think the rendering of GUI interface has to be as fast as possible (GUI interface will then have very quick responsiveness) while allowing new features we bring (e.g. UI-profiles - change OpenOffice to MicrosoftOffice in a GUI functional point of view and theme).

Yesterday I was thinking not to use GTK-libraries-like technology but rather something like LEGO toy technology. You have simple shaped bricks and you build a car or house with them. In GTK point of view you have for example a text-field and a button. But the button is more simple. It doesn't have any label or icon. The label is a single brick, the icon is a simple brick. You have to put icon and label brick in the button brick to have toolbar button. The GTK uses single brick called ToolbarButton (or something like that). Whether it uses the MakeButton - MakeLabelInButton - MakeIconInButton functions doesn't matter. Still to build GUI you have to choose one of preprogrammed buttons (ToolbarButton). You can say that it is easy to build applications with GTK and it's less time consuming. Well we can do the same with the smaller and simpler bricks of UI-LEGO by using macros and templates in a GUI Design Developer Environment.

And more. We can create programmable UI-LEGO. In GTK library each brick has its behavior and functionality. Developer must follow these or create his own GUI library. But with something like programmable UI-LEGO we can easily build for example any kind of button. If I go to the extremes we can for example create button inside which there will be a Call of Duty game running. I know it is not good example and is very extreme (BTW that is one of the crazy awesome ideas I had Yesterday :) ). To speak of usage, with our programmable UI-LEGO we can easily make a Windows 8 Metro tiles (what is a square where a lot of different informations are displayed - for example a web page, weather info, YouTube movie etc.). With our programmable UI-LEGO we just put together a button brick and for example box brick inside which the middle part shows or renders streamed TV. With this technology we can easily change old toolbar style of common Linux applications to Microsoft Office Ribbon toolbar. And more. Applications UI developers and designers have freedom on how the application UI will look and behave. Thus Adobe can make a specific GUI for the whole Adobe Creative Suite (Adobe CS) application pack and moreover a specific GUI for each application in a pack (Photoshop, Illustrator, Flash etc.). And we can easily create a new Shell and very differently change its look and add new features in further versions. This is what brings to UI developers and designers a lot of freedom in creativity and a lot of fun.

Also I don't think that main part developers will have less freedom. I meant it to allow them to concentrate on the main task the application is targeting. Again. I don't mean that main part developers will have to use our new technologies. I don't mean that main part developers MUST follow our guideline. I'm saying that main part developers will have a lot of freedom to decide what guideline or maybe what technology will they use for accomplishing the main goals and conditions of creating a very specific application.

To push my imagination, instead of standardized windows in a desktop system (handled by window manager) we can have windows to look more like Gadgets. It means, when you open a clock application then the opened application will exactly look like wall watch or 3D solar clock (used somewhere in a centuries back) with its perfectly rendered shadow of the stick. Can you imagine that? If not, tell me and I make some images to show it. Then we can have UI for small children with a lot of colors, big funny fonts which behaves more like a game. Or we can have a desktop looking like comics story. The target of our goal in creating middle part library could be to simplify this to UI developers and designers allowing them to have a lot of freedom.

Well we can start with for example to make the middle part library which uses GTK library for creating a GUI (BTW is it fun to start exactly with this after all I have said above? :) ).

I'm not sure what is (for me) the goal of this group. I laid down my imagination but it couldn't be my own goal in this group. A good fun could be to show Microsoft and other companies what is possible with simple Linux. Shocking them and beat them with some great idea could be a very interesting goal.

But I still understand that computers are used for work and old and/or nontechnical people. Thus the UI design with the programmable UI-LEGO could look exactly like old computers GUI. Again. This freedom I would like to leave on application developers, UI developers and UI designers and other application and desktop creators.


Reply to this

-

 Re: Re: Re: Goals

 
 by user333 on: Oct 30 2011  
Score 50%
user333user333

The "LEGO" idea sounds good, but would this require our own widget toolkit?

Here is the single most important thing you can ever read:
http://contenderministries.org/romanroad.php
If you agree, put this in your signature too ;)
Reply to this

-

 Re: Re: Re: Goals

 
 by MasKalamDug on: Oct 30 2011  
Score 50%
MasKalamDugMasKalamDug

Wow - I really set you off. I can't think through any great part of it instantly so I'll just mention one problem - the inner interface.

The inner interface is between the user interface script and the application code. You mentioned shared memory and to some extent this must be used but there is a problem. It arises when one side changes something - then the other side needs to know there was a change. I dismiss polling without any real analysis and conclude a signal must be sent. But why not just send the change?

That is, the shared memory becomes virtual. It does not exist (except in the documentation). The front end and the back end exchange messages all of which look alike - "set the value of A as X". "A" being some variable in the virtual shared memory. We might have to use some real shared memory to set a string or the like.

Still looking at gedit I found as immediate question. What happens if I want to "Open"? The process of locating a file and loading it is complicated enough to require a thing that looks like a whole application. But it's not an application in the sense we want to use that word. Call the file locater and things like it "utilities". They are supplied by the operating system for applications to use.

Now the question is - is running the file locater utility a function of the front end or the back end ? Could work either way. We need a policy and we should have some good reason for having such a policy. I hope we can avoid any dependence on how the file system works.

I will keep on reading your post which I think I agree with but I might identify other topics I want to comment on.


Reply to this

-
.

 Re: Re: Goals

 
 by user333 on: Oct 30 2011  
Score 50%
user333user333

Your experiment with gedit sounds really exiting! So basically you are going to try to use a standard gedit program, intercept the UI, and replace with HTML, right? Please post the code if you are able to do this!

Here is the single most important thing you can ever read:
http://contenderministries.org/romanroad.php
If you agree, put this in your signature too ;)
Reply to this

-

 Re: Re: Re: Goals

 
 by MasKalamDug on: Oct 30 2011  
Score 50%
MasKalamDugMasKalamDug

The way I work is to conceptualize first before I write a line of code. Right now in this process I am unsure I can use real HTML and, to tell you the truth, I would be just as happy to break with HTML which has a number of features I am not fond of. But the result should be HTML-like. Of course I could not then use a normal browser. But this is all an experiment so who cares?

There are already a number of text editors that run over the web. Mozilla's editor should be open source. So, if I were really interested in making code I should go there and see what they are doing. But this is a learning experience - not a coding project.


Reply to this

-
.

 Re: Re: Re: Re: Goals

 
 by novomente on: Oct 30 2011  
Score 50%
novomentenovomente
Home

One more thing I forgot to say. It is about the programmable UI-LEGO. Most programmers could think that it should be a library similar to GTK or Qt etc. For us it means that we have to make the library. Today I found out that it can be a library OR it couldn't be. As I said our goal could be to simplify things. So instead of programming a library we could just write a source code pack.

The finished source code pack has the structure as a library i.e. has function name convention, functional convention, logical convention etc. Application developers could use our source pack to create an application. The developers could use our source pack and create a library which will be single application specific or more application specific (for example Adobe CS) or it can be exactly something like GTK or Qt library shared across Operating System. The developers can use our source pack and reprogram it or tweak it or use chunks of it to create things to accomplish their goals in development.

So our work wouldn't be to make GTK, offer it to developers and say 'use it for your application if you like'. Instead we offer a programming techniques, sources, new technologies (for example new HTML for writing UI-LEGO) and guidelines. And if developers find out that our work is good, they use it. They change it. They create new solutions and bring new ideas coming out of it. They will be free to create what they want and what they need (developing for fun or developing companies for money).

And we can do the same. We can make libraries, we can make new Shell. We can bring new ideas, solutions, new guidelines, new technologies etc. (we can play and work as Bill Gates said once).

But back to the land. Yesterday I found out that we can for example make the middle part to use GTK library and/or Qt library etc. (speaking of probably dynamic libraries). Then we can have 2 files describing UI-profile of each (i.e. GTK or Qt). Then we can make an application which, when started, will detect whether it runs in GNOME desktop or KDE desktop and decide to load and use GTK library or Qt library (I'm not sure if KDE uses Qt). Then when running application with GNOME desktop it uses GTK library and look and behave as a GTK application. Similarly with KDE etc. We can of course make a middle part library which uses chunks of both GTK and Qt (for example it will be a GTK application with Qt ToolbarButtons). But this is only possibility not neccessery for creating real life applications.

I have to note that what I said today is only an idea coming out from imagination. And it's a matter to discuss and to push our imagination (rather than to vote for it). To bring it and to bring others ideas in reality will most probably make a very different final work. So I would like to push the discussion, push our imagination to bring ideas, push our brains to bring solutions and as Mike Gray says to think and decide our goal (which of course must be reachable for us).


Reply to this

-

 Re: Re: Re: Re: Goals

 
 by user333 on: Oct 30 2011  
Score 50%
user333user333

I understand that this is just for you to learn, but I'm interested to see how you do it ;) It could be really important.

Here is the single most important thing you can ever read:
http://contenderministries.org/romanroad.php
If you agree, put this in your signature too ;)
Reply to this

-

 Front End - Back End

 
 by MasKalamDug on: Oct 31 2011  
Score 70%
MasKalamDugMasKalamDug

I formulated an application model where there was a front end, a back end and virtual shared storage.

I use gedit as a test bed but first lets start with the simplest possible text handling - a file browser. In a file browser the front end simply displays the contents of the file - nothing more.

I would say the virtual inner interface was, at a minimum, a struct like this:

Void* file_address
Int file_length
Char character
Bool step_right
Bool step_left
Int error

The two ends exchange messages saying "x = y" where x belongs to the interface and y is a new value to assign to x.

The front end starts by running some file-finder utility to find a file to display, then loading that file into data memory and finally sending two messages:

front: file_address = ...
front: file_length = ...

Then it starts to display the text. It gets the successive characters as follows:

front: step_right = 0
back: character = '...'

When the file is exhausted and there is still one more step_right

back: error = ...

After that every can be done by the front end. But that requires the front end to maintain a duplicate copy of the text. We can do a lot better by adding pair of data to the inner interface

Bool get_cursor
Cursor cursor

Cursor is an opaque type the front end does not understand. But the front end can save a cursor value and compare two cursor values. The get_cursor variable is really a command - as are step_right and step_left - that asks the back end to supply the value of cursor. Then the front end can, for example, remember where the cursor was when each page began and if it wants to, say, go back one page it sends:

front: cursor = ... // the value is saved cursor value

In order to get to an editor we need to bring in an edit add-in. I am cheating a little here because I am really assuming the browser is just the editor with edit turned off. A simple edit capacity can run with four more command in the interface:

Bool insert_left
Bool insert_right
Bool remove_left
Bool remove_right

The remove commands return the character removed and the insert command inserts the character.

The way add-ins work is that the messages are realized as function calls to one of two functions - front or back. The arguments are an identifier for what variable and the value to use. The back end starts by a select on the variabl. If it can't find the variable it passes the problem to the first add-in.

Here I am designing the back end. This is certainly suggestive that the front end needs its own add-ins.

This is far from finished. Another installment another day.


Reply to this

-
.

 Re: Front End - Back End

 
 by novomente on: Nov 1 2011  
Score 50%
novomentenovomente
Home

David. What programming language do you use? C++? I would like to know to understand your comment and to communicate with you well.


Reply to this

-

 Re: Re: Front End - Back End

 
 by novomente on: Nov 1 2011  
Score 50%
novomentenovomente
Home

BTW - I'm Michael


Reply to this

-

 Re: Re: Front End - Back End

 
 by MasKalamDug on: Nov 1 2011  
Score 50%
MasKalamDugMasKalamDug

In the comment I used an ad hoc language I made up for the comment. I borrowed the type specification from C.

When I write compiler code I use 1990 Standard ANSI C - with one extension - I allow declarations anywhere in blocks instead of just at the beginning. I would prefer to use assembly language - but that simply is not possible any more.

I have coded in C++, Java and GOK more languages and decided I like things SIMPLE - hence C. I can do objects just fine in C without further extensions. Again the object system in GLib / GTK+ is, in my opinion, too complicated.

But this is not real code. This is conceptualization. At this level I usually talk about objects and messages. The reason I got closer to code was to see whether the "shared memory" approach would work and what consequences it would have.

It appears that shared memory - real or virtual - will work and that is good. The way I am setting up the inner interface though requires a lot of messages and I wonder about speed. So I have decided, so long as I am just conceptualizing, I will ignore efficiency.


Reply to this

-

 Re: Re: Re: Front End - Back End

 
 by MasKalamDug on: Nov 2 2011  
Score 50%
MasKalamDugMasKalamDug

I wrote down a description of the gedit screen in XML (I am not up to snuff on HTML5 and HTML4 is too clumsy). It is surprisingly long so I am not posting it. It is less edifying than you might expect because of problems - both with gedit and with my concepts. I'll post if you ask me to.

There are two big problems with gedit. The larger is how highlight mode is specified. It should not be done the way it is done. Rather highlight mode should bring up a dialog along the lines of the file selector. Second, there are capabilities that are not reached in the menu - like tab width and insert mode in the status line and the last two item on right click. The whole idea of the menu is that everything the application offers is presented there.

The biggest single flaw in my concepts is that I have been considering the picture shown in a sub-window that triggers a specific action is a property of the widget that carries out the action. But that isn't right and the picture must be under front end designer control. For example, you can execute a "paste" action from the GUI (not to mention the keyboard) three different ways - menu, toolbar and right-click - and the picture is different each time. Of course there should be only one paste "widget". I am. at the moment, unsure how I want the pictures manipulated - but apparently not in the widget.

Another problem is, in my opinion, the lack of differentiation between GUI actions that impact on the back end and those that do not. For example, clicking on one of the entries in the menu bar, say "_File" does nothing to the back end. In theory, at least, an action that does not impact on the back end could be omitted from the GUI.

Yet another problem, which I knew about before I started is that utilities like the file selector have a separate front end of their own and a separate back end and my vocabulary was not up to expressing those facts.

This stew is a long way from being cooked.


Reply to this

-
.

 Re: Re: Re: Re: Front End - Back End

 
 by novomente on: Nov 6 2011  
Score 50%
novomentenovomente
Home

Can you join FluiDE group on google site here (anybody can join):

http://groups.google.com/group/fluide/

You can paste XML as a new post there. Unfortunately Google Groups don't allow attachments anymore. So I suggest Mike to create FluiDE on Google Code (with name like "FluiDE-attach" or some name, not name "FluiDE" which could be used for FluiDE sources) which we could use for attachments (2GB space). In discussions we can then post URLs to the files stored on FluiDE-attach google code.


Reply to this

-

 Re: Re: Re: Re: Re: Front End - Back End

 
 by user333 on: Nov 6 2011  
Score 50%
user333user333

done :)

http://code.google.com/p/fluide-attach/

Here is the single most important thing you can ever read:
http://contenderministries.org/romanroad.php
If you agree, put this in your signature too ;)
Reply to this

-
.

 Re: Re: Re: Re: Re: Re: Front End - Back End

 
 by novomente on: Nov 6 2011  
Score 50%
novomentenovomente
Home

Wow you are quick :)

I found that google code project has 4GB free space and maximum size of an uploaded single file is 200MB. The project is well to administer and to join the group must be made by project Owners under People page. For info I'm adding a link:

http://code.google.com/p/support/wiki/HowToJoinAProject

I think that for making attachments it is necessary to be a Committer. Commiters are allowed to create downloads but not allowed to delete them. To delete downloads are allowed only Owners. This help describes permissions:

http://code.google.com/p/support/wiki/Permissions

You can also create User Groups and make permissions to each group:

http://code.google.com/p/support/wiki/UserGroups

And last thing. Could you add a FluiDE Google Group address to the Fluide-attach project's link? It should be a regular link (added in Administer -> Project Summary -> Links
The FluiDE Google Group could be a mailing list where another people can ask for join the group (aside gnome-look.org group). There is also a special Google Group link there under Administer, but it is for automated emails. For info here is a link:

http://code.google.com/p/support/wiki/FAQ#Google_Groups


Take your time. Make it when you have time for it and only if you decide it is the thing to be done.



-

 Re: Front End - Back End

 
 by novomente on: Nov 6 2011  
Score 50%
novomentenovomente
Home

Right now I'm thinking of the other idea I mentioned. Multithreaded modular programming of applications. It'll take some time.

BTW - your work with gedit as you described above is good. The disadvantage is what you said - efficiency (probably). I'm thinking about it right now and probably continue tomorrow.


Reply to this

-

 GUI interface atoms

 
 by MasKalamDug on: Nov 5 2011  
Score 50%
MasKalamDugMasKalamDug

I have reached the conclusion that a user of a GUI interface can, in the final analysis, do only three different kinds of thing -

(1) Select a member of a tree (a list is a special case of a tree)

(2) Maintain a tree (inserting and removing members)

(3) Tell the back end to act.

This is rather drastic and I wonder if I may have gone off base. This seems to work even for GIMP. Can anyone see that I have missed soemthing?


Reply to this

-

 Window Managing

 
 by user333 on: Nov 6 2011  
Score 70%
user333user333

I was thinking about how window management could be done better, and I think I have found a way that combines ALL the different approaches:

Overlapping (Windows, Mac, and Linux)
Tiled (Old Windows)
Fullscreen (Tablets, Phones, Windows 8)

This is done by using a tiled layout similar to Blender 2.5's non-overlapping window system. Each "frame" could would be it's own desktop, into which an icon of a program can be dragged, making fill the frame. Then, if two icons are dragged into the same frame, it becomes a classic desktop with window borders. Each frame could then be "maximized" and "restored", so you could have a full-screen app, full-screen desktop, or a multi-tasking view.

The main advantage of this is that you can have your windows any way you would like them, all in the same interface(similar to the advantage of my dynamic panel system). So, if someone doesn't like tiled windows, a classic desktop is only a click away.

I'm going to post a mock-up, so if you don't understand this wait until then ;)

What do you think of this idea?

Here is the single most important thing you can ever read:
http://contenderministries.org/romanroad.php
If you agree, put this in your signature too ;)
Reply to this

-
.

 Re: Window Managing

 
 by Padster on: Nov 6 2011  
Score 50%
PadsterPadster
editor
Home

Sounds interesting, I'd like to see a mockup.

101010
Reply to this

-
.

 Re: Re: Window Managing

 
 by user333 on: Nov 7 2011  
Score 63%
user333user333

Here it is!
http://opendesktop.org/content/show.php?content=146614

Here is the single most important thing you can ever read:
http://contenderministries.org/romanroad.php
If you agree, put this in your signature too ;)
Reply to this

-

 Re: Window Managing

 
 by MasKalamDug on: Nov 6 2011  
Score 50%
MasKalamDugMasKalamDug

I observe that full-screen is a form of tiling. So there are really only two modes.

Windows 1 was tiled as were the demonstrations I saw in the 70's by Xerox Parc and IBM. But overlapping windows seem to offer more freedom. I am personally of the opinion that they offer too much freedom - but I am sure there people out there who love them.

We do not want to give up windows overlaying windows - for example, dialogues. So we must work with the idea of z-stacked windows (I think this is what many people mean by frames). But if I display a dialogue overlying an application I really should be able to move it around. A dialogue probably doesn't ever call for resizing - but other things for which resizing makes sense might be being displayed. So I am back again to where I started.

So I think I end up with a z-stack of windows of varying (and changeable) sizes displayed as though lying one on top of the other. Within each window everything is tiled. I am thinking of one window per level in the stack - otherwise I have to worry about windows colliding.

I can imagine a system - call it sub-tiling - where the windows at a particular level can be moved around and shove each other aside when they collide. I have never seen such a thing implemented.

Now the question is - did I say the same thing you did? Or is there some difference of opinion between us ?


Reply to this

-
.

 Re: Re: Window Managing

 
 by user333 on: Nov 7 2011  
Score 50%
user333user333

For the most part, I would agree with your observations, and my idea is one way to address the issues you brought up :)

The idea of colliding windows is very interesting.

Here is the single most important thing you can ever read:
http://contenderministries.org/romanroad.php
If you agree, put this in your signature too ;)
Reply to this

-

 Re: Re: Re: Window Managing

 
 by MasKalamDug on: Nov 10 2011  
Score 50%
MasKalamDugMasKalamDug

My latest thinking about menus:

Menus are separate GUI machines embedded in application GUI's.

A menu is a hierarchy of menuboxes. There is an initial menubox which can, under certain circumstances, open subordinate manuboxes which in turn ... Thus at any moment there is a stack of menuboxes.

The pointer is usually in the topmost menubox. If it leaves that box I check the next lower box and so on. If the pointer is in none of the boxes I keep checking after each pointer move until something happens. If what happens is a click outside any box the menu terminates. At the moment I am considering only the screen and the mouse - the keyboard will be added later.

Each menubox is divided into lines. Each line has a function (perhaps null). Each subordinate menu box is opened by moving the pointer into its parent line. Thus in all the menuboxes except the topmost one of the lines is active in the sense that its subordinate box is in the stack.

If the pointer enters one of the menuboxes in the stack but not the line that is active then the stack is popped off to that level and the logic that follows is that of the pointer in the topmost menubox. If it enters at the active line the stack remains unchanged. Thus the pointer may be in the topmost box or the active line in a lower box.

If the active line in a lower box is clicked it may truncate the stack or it may do nothing - practice differs.

Otherwise the menu disappears when there is a click occurs. If in the topmost box the widget corresponding to the line is notified - otherwise nothing happens.

When a menu is active the keyboard may have accelerators. Each menu box can have a set of keys that jump the focus to a particular line in the box - all other keys are ignored. If the pointer moves (or leaves its current line - practice differs) its setting of the focus takes over again. Accelerators are not to be confused with shortcuts which, in my formulation, are added later by an independent system.

Otherwise all the keys except the move keys are ignored. In the usual vertical menu the up and down keys move from(non-grayed) line to line and may cycle from top to bottom or vice versa. In a horizontal menu the right and left keys do the same. The home and end keys may be enabled to move to the ends of a menu box. In a vertical menu the left key pops one level off the stack and the right key truncates the stack.

The menu proper is a widget that grabs the focus (and has it own internal focus) and displays its boxes without regard to the rest of the GUI. Hence a tear off menubox is an obvious thing to provide. Each submenu would be movable without regard to the others and would be brought to topmost position in the display. Note that that makes the display stack and the menu stack potentially different. However tear-off menus seem not to be popular these days - and, in most implementations have a more complex meaning than I have ascribed to them.

The menu is triggered by something in the application GUI. Conversely the shortcut system wants to leave its marks all over the menu system. And how to add-ins fit in? I visualize the menu as displaying a description - possibly XML - that a user can edit. Obviously a user can add an add-in if she can edit. So, I assume could, a add-in installation program.

The shortcut system is also a description. I assume a list of shortcuts and what they do - some of which are things the menu does. So if I want to make CTRL+P do the same thing as Print in the File menu (and to display it in the File menu) I need a way for the shortcuts to refer to the menu lines and for both of them to refer to widgets. Since the shortcuts are imposed on the menu I could redirect menu-related shortcuts to the menu and from there to the widget. That is, make the shortcut a shortcut to the menu rather than to the widget the menu calls. This needs more study.


Reply to this

-
.

 Re: Re: Re: Window Managing

 
 by novomente on: Nov 13 2011  
Score 50%
novomentenovomente
Home

Handling windows and desktops by Mike is interesting. Also David's commentary to it is interesting. So I thought a few tens of minutes and then realised, that we can have overlapping windows which can become tiled to each other and to a desktop. I made an animation describing the basics of this thought. It goes well with Mike's windows and desktop handling (Blender style) and also with Mike's Dynamic Panel System.

Moreover every last ideas on windows handling solves my problem on one of my 2 years old idea on managing desktop and managing/launching applications. Although the idea I had is perfect easy solution, for me, it sounds a bit conservative. I would like to push imagination more forward to the future. But I understand that conservative solutions must be part of our project. And I know exactly that new ideas comes out from old grounded ideas.

So lets continue by bringing the ideas around today's computer UI. More lets imagine we have more toys to play with. For example lets imagine that we have an LCD very close to our keyboard and we can multi-touch it with fingers, draw and write with stylus and other yet unknown toys and imagine we are working with today's applications and desktop with those toys. We can for example draw a desktop in GIMP or Inkscape (concept or some easy image, or use pasted images), place it fullscreen on the LCD and imagine we touch it with fingers and stylus and manage it. When you would like to make for example opening a menu, you can just modify the GIMP image by adding a menu there, save new image and place it to a new folder with the previous image and then... Open the first GIMP image fullscreen on the LCD, do or imagine the move or touch with mouse/fingers/stylus/other-toys and then switch the previous GIMP image to the second modified image (where opened menu is) to see the action. Or you can do it in your imagination but sometimes, when you see the action in reality, it shows a new functionalities to you.

You can also use a web interface with link images in a web page or with image-mapped links (Kompozer + Firefox/Chrome), or OpenOffice.org Presentation, or use Salasaga, Synfig etc.

To look forward we can place our minds in the future and then we can look back from that point of view. It is like to travel in a ship to the space and then see our Earth from there. And suddenly you can realised that you have a lot of conservative ideas than you had staying on the Earth ground. I'm talking from my experience (with imagination and ideas of course not with travelling the space :) ).

link to animation: http://novomente-activities.blogspot.com/2011/11/dynamicly-tiled-windows.html


Reply to this

-

 Re: Re: Re: Re: Window Managing

 
 by Padster on: Nov 13 2011  
Score 50%
PadsterPadster
editor
Home

nice animation, look really promising, to have tiling and non-tiling together, so you can use whichever.

101010
Reply to this

-

 Re: Re: Re: Re: Window Managing

 
 by MasKalamDug on: Nov 13 2011  
Score 50%
MasKalamDugMasKalamDug

I can imagine a keyboard with a small display on each key under program control so that the keyboard can be freely changed to show different key assignments. Or even communicating back to the user by blinking or changing color.

I have been fooling around with an iPad2 and I find the tablet face keyboard almost impossible to use comfortably. The touchscreen GUI is very nice otherwise and anything we do should be able to handle it - and one assumes more.

But I dont think keyboards are going away. The mouse might though.

Voice input is another kind of peripheral. I am inclined to doubt the utility of the Star Trek kind of command input. But I would dearly love to have it for text entry (like this post)


Reply to this

-

 Re: Re: Re: Re: Window Managing

 
 by user333 on: Nov 13 2011  
Score 50%
user333user333

It looks interesting =) I normally wouldn't compare things with my own ideas, but since you designed it so that it could be used with my idea, I will ;) If your idea was used with mine, one of them would be unnecessary. Since your idea and mine are both different solutions to the same problem, I wouldn't try to merge them, unless you see a need to allow tiling inside a tile. The main advantage of your idea is that windows can be resized in any way. It might be hard to target the window edge with your mouse, though, and it may not be apparent that you need to double click the edge if no one told you. You could make the windows "snap" at a certain distance, which would solve this problem.

I think that my idea is easier to manipulate quickly, but I don't think it's perfect either. A really big problem I see with my idea is that it complicates things a bit too much.

I see just as many good points for either idea, so the only way I would know how to decide would be to actually try them out. Maybe there could be a way to create a working HTML mock-up, and then we could make better decisions based off of actually using it.

Here is the single most important thing you can ever read:
http://contenderministries.org/romanroad.php
If you agree, put this in your signature too ;)
Reply to this

-

 Re: Re: Window Managing

 
 by novomente on: Nov 13 2011  
Score 50%
novomentenovomente
Home

Is this animation what you meant by saying:
Quote:
I can imagine a system - call it sub-tiling - where the windows at a particular level can be moved around and shove each other aside when they collide. I have never seen such a thing implemented.


Animation: http://novomente-activities.blogspot.com/2011/11/dynamicly-tiled-windows.html



BTW - Look at Project Looking Glass - 2D interface in a 3D world. I had a demo CD but it's out. Can for example Windows be minimized aside desktop as in Project Looking Glass, or as you say be shoved aside?

link to project (it is turned down since Sun Microsystems does not exist):
http://www.youtube.com/watch?v=zcPIEMvyPy4&feature=related
http://en.wikipedia.org/wiki/Project_Looking_Glass


Reply to this

-

 Re: Re: Re: Window Managing

 
 by randallovelace on: Nov 13 2011  
Score 50%
randallovelacerandallovela ce
Self Employed - Computer Repairs

I like the way that worked - and that is a lot like how Blender's internal windows are resized.

Randal Lovelace
Reply to this

-

 Re: Re: Re: Window Managing

 
 by MasKalamDug on: Nov 13 2011  
Score 50%
MasKalamDugMasKalamDug

Your mockup is almost but not quite what I had in mind when I said I had never seen an implementation - not that I had ever seen your idea before either. I was visualizing a system where the windows push each other around but never change size. There would have to be some kind of 2-D dynamics and it would be more fun to allow the windows to rotate.

But I don't think this is worth bothering with except maybe as a show-off project.

I may be a stuffy old cat but I think "beautiful" interfaces are counter-productive. For example, on a current iMac there are a bunch of "icons" placed so as to look like they are sitting on a table top. (And this table top which is obviously a desktop image is NOT what Apple calls the desktop). I think much is lost and little is gained by such gingerbread.

This is a fundamental design issue. I am with the Bauhaus on this. Ornamentation should be avoided.

But I am aware that lots of people like ornamentation and 3-D effects and so on. So all I ask is that under the fancy GUI there is a simple GUI with the same functionality.

Question: Why do you want to use anything except tiling ?


Reply to this

-

 Re: Re: Re: Re: Window Managing

 
 by user333 on: Nov 13 2011  
Score 50%
user333user333

Quote:
Question: Why do you want to use anything except tiling ?


The reason is to keep support for traditional programs that can't handle tiled windows.

About your comment about "beautiful interfaces" I would agree to some extent that flashy stuff is counter-productive. But, it is a requirement for an interface to look attractive. The difference is that while something like the compiz desktop cube is useless, some visuals, like hover animations, are essential for the user to interpret what the computer is doing. Interfaces don't have to look ugly, they just don't need junk. In fact, when I have to use a really ugly interface I'm distracted by how ugly it looks.

I think, however, that big icons rather than text have a major technical advantage: They are easily target-able. (This isn't an advantage in OS X, however, because the icons change position with that silly "zoom" animation) Another advantage is touch: your fingertips are more round shaped and can click a square area more easily than a small line of text.

Here is the single most important thing you can ever read:
http://contenderministries.org/romanroad.php
If you agree, put this in your signature too ;)
Reply to this

-

 Re: Re: Re: Re: Re: Window Managing

 
 by MasKalamDug on: Nov 13 2011  
Score 50%
MasKalamDugMasKalamDug

Thank You

I admit to having little or no interest is keeping legacy applications running. It should be easy to retrofit their GUI to tiled. Mostly it should be a case of removing capability. The only case I can think of that would bother people is when they bring up one application on top of another and are used to having the top application smaller than the screen and some of the lower application sticking out so that they can move the pointer into what sticks out and get the lower application back on top. This can be handled by a tabbing setup.

Are you aware of any situations where untiled applications might not be easy to tile ?

Tastes differ a lot. I consider the interface I am looking as I write this (the one supplied by Gnome-Look) as ugly because far too cluttered. Somebody must like clutter because they built this interface.

I agree that some animation is necessary - if only an animated cursor. The only time the GUI should not be feeding back something should be when it is doing nothing (assumed by user choice).

I have nothing against beauty per se - but so many attempts at beauty are so misguided that I favor not trying. You must have seen pictures of Victorian (late nineteenth century) interior decoration. They liked that clutter.


Reply to this

-

 Re: Re: Re: Re: Re: Re: Window Managing

 
 by user333 on: Nov 13 2011  
Score 50%
user333user333

Well, dialogs would have to be layered, but if you think they would work that would be great :) I think it would be faster to get out the first alpha versions with some legacy support(not necessarily in this area), so we can focus on making the newer ideas more stable before we start working on making existing programs feel native.

I think that the window manager should be totally interchangeable and separate from the panels so people who want something else can use it. We could even design the default window manager to be scripted, allowing someone to create their own way of doing things.

We could have things like icons sizes and padding configured using a style sheet. Then a style that works well for mice could be used on desktops, and another style for multi-touch devices.

Here is the single most important thing you can ever read:
http://contenderministries.org/romanroad.php
If you agree, put this in your signature too ;)

-

 Re: Re: Re: Re: Re: Window Managing

 
 by MasKalamDug on: Nov 13 2011  
Score 50%
MasKalamDugMasKalamDug

Forgot to add. I am all for bigger places to touch but not necessarily just by making icons bigger. We should always anticipate a touch screen and make every touch area big enough - by whatever means is suitable (even wide margins) - for a finger.


Reply to this

goto page: prev   1  2  3  4  5  6  7 

Add commentBackHomeCreate new groupView all groups



-
Xfce-Look.org
-
NEWS
-
Linux42.org
-
Popular Groups
-
Newest Groups
-
FORUM
-
People
-

Copyright 2004-2016 Xfce-Look.org Team  Legal Notice
All rights reserved. Xfce-Look.org is not liable for any content or goods on this site.
You can find our FAQ here.
All contributors are responsible for the lawfulness of their uploads.
Please send us a notice if you spot an ABUSE of the website.
Information about advertising in Xfce-Look.org.
Developers can use our public webservice interface. More information here: public api
For further information or comments on this site, please send us a message
Xfce is a trademark of the Xfce Project
Content RSS   
Events RSS