FluiDE (New Computer Interfaces Discussion)

Invite people to join
Join group
Activate message notification

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

goto page:

1 2 3 4 5 6 7

I guess we'll start with menus ;)

by user333 on: Jul 17 2011

Score 50%

In this group we will discuss what could be done better about interfaces, and then try to code a better way if possible. So, we might as well start out by talking about one of the oldest UI elements: menus.

Are the current menu bars still relevant to modern needs? The link in the description has a very interesting implementation of menus, which is the main reason I included it. (the creator of the interface is OK with us taking inspiration from his mock-up.) What do the rest of you think about this idea? The idea of having relevant and frequently used functions visible is really appealing. The one downside I see is that the top-level menu is not visible when you enter the sub-menu. Would a Blender-type menu work better? I find that a lot of inspiration can be taken from the Blender 2.5 interface. It is unbelievably easy to get done what you need to, without the program getting in the way.

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

Re: I guess we'll start with menus ;)

by naolloan on: Jul 18 2011

Score 50%

naolloan
Home

Hello User333, and to all of you.

To introduce myself would be a good start : I'm a French graphic designer (amongst other things) with a special interest in open source software and good UI design. I've made very minor contributions to the kde project under the nickname "eriolloan", mostly icons and mockups (which you can find for some part on my flickr page http://www.flickr.com/photos/28945194@N05 and for the other part on my outdated blog http://erioll.blogspot.com/ ...

I fell in love with KDE but got disappointed by its lack of polish aestetically-wise and its (at least to my taste) disappointing usability, and felt that I alone am in no position to contest the choices of the good people bringing us one of the most advanced open source DEs out there. I often dreamt of reinventing the wheel too, but this needs to be undertaken by a motivated and team, not a single individual.

So I'd love to contribute to your endeavour with all skills at my disposal : Branding, Icon themes creations, UI paradigms (in which I'm no approved expert, just an educated user)... and surely other qualities I can't pinpoint at such a late hour.

Blender menus sound like a nice concept. I'll investigate (=install and test).
I for one think we should learn from most existing DEs and the struggle they're facing when trying to adapt to the large variety of devices they aim to run on. I'd keep in mind that whatever we try to accomplish, it must provide a coherent and seamless behaviour should it be used on various devices. Reinventing the wheel is a big task, but in this matter it's also a big opportunity most DEs don't have.

There's ALOT to think about and to discuss. Now, I think the good start for this project to get serious would be to set up a wiki and an IRC channel to lay out the basics of this project : philosophy, vision, goals, tasks. Both the wiki and the irc channel requiring skills I don't have as of now.

I hope you're all motivated and ready for a long ride. As for me I'm thrilled and I wish us the best in this new project.

What about you? Who are you and what are your motivations, your areas of expertise and your take at this?

Best regards.
Adrien

Re: Re: I guess we'll start with menus ;)

by user333 on: Jul 18 2011

Score 50%

It's great to have you help! I'm have some skills in graphic design, mostly in free programs, but it would be great to have someone who is more professional than I am. I also know some web development, I plan to learn GTK inside and out, and I love UI design. Right now I'm being help back from learning GTK because I'm using Ubuntu, which still has GTK2 until the October release. I hope to buy some USB drives and install Fedora so I can experiment with GTK3 without breaking my Ubuntu install.

My motivation to do this is to have some fun ;) Also, I have had difficulty joining other open-source projects, and I wanted to get some experience creating a final project. (I've helped in some projects, though, including creating the new CD cover for ReactOS)

I agree that we really need a wiki and irc channel, but I don't want to put out the money. Would a google wiki be good enough for now? I can set one up if we can think of a good name for this project. I have one idea: if we could pick a plant/fruit/animal that would describe the project's feel, what would it be? "Citrus Project" might be a cool name. Any other ideas?

About being consistent on all devices, we must make sure that not only is the interface consistent, but also well-suited to each device. For example, Win7 will work on a tablet, but it is not well-suited at all.

I would say something like this for the goal:

This project will be the most usable, visually appealing interface, and nothing will be used just because it is traditional.

Our motto could be "Reinventing the Desktop." Tell me if you another idea, I'm just putting my vote in.

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

Re: Re: I guess we'll start with menus ;)

by MasKalamDug on: Aug 27 2011

Score 50%

There seems to be a growing realization that menus, as usually implemented, are an obsolete idea. There should be, somewhere, a unified list of everything an application can do. In that sense menus are not obsolete and should be, in fact imperative. I observe that Gedit, for example, has actions in the right click pop-up that are not in the main menu. I consider that bad practice.

The everything menu IMO should not be a routine tool. I think of it as more part of the help system. But it should be accessible when all else fails.

Ubuntu (the only form of Gnome I am familiar with) has an interesting system level menu with three entries on the top bar - applications, places and system - which, sort of, is a menu of all the installed applications and even the files. I think this is good idea but the implementation needs to be redesigned.

So menus should survive but not in their classical implementation.

Re: I guess we'll start with menus ;)

by gilfcp10 on: Aug 2 2011

Score 50%

gilfcp10

I'm glad to see someone thought of making this group, congratulations :)
I've started a few months ago making a new UI but it wasn't easy to have time for it and I can't do a lot alone (I didn't even understood how to "talk" to X to get the windows).

One of my ideas involves menus:
Menus and toolbars would be "killed" and replaced by something like small windows/boxes in the right (or left) side. Those boxes don't only contain the most used options but also the most obvious options (if you select an image you don't expect to see the bold text button). Each box is a category/group of options. It's true the boxes could be huge to have all the options but they are small until the user passes the mouse over one of those boxes (or touches the title of a box, the UI should be "touch friendly"). When the box is small it shows what's more likely to be used, when it is "big" it shows all the options. These boxes can also be moved inside the window and they can move automatically so they get close to the mouse if you select text, for example.
With this you would be able to do much more with a single click/touch without filling the whole screen with buttons. I don't really know how to explain my idea and I never programmed it, I can try to draw if you want.
What do you think?

Re: Re: I guess we'll start with menus ;)

by user333 on: Aug 5 2011

Score 50%

Nice idea :) Do you think you could make a sketch that explains it?

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

Re: I guess we'll start with menus ;)

by MasKalamDug on: Aug 27 2011

Score 50%

I model the display screen by two parallel arrays - one of pixels and one of widget ids. In general the focus in on the widget parallel to the pixel where the mouse sprite is. The mouse handler looks at the widget after every mouse move and if the new widget is not the same as the old widget it sends a "lose focus" message to the old widget and a "gain focus" message to the new widget. At the same moment the mouse handler restarts its timer which is set for around a second. Whenever the timer succeeds in counting down it sends a "dwell" message to the widget and resets itself. The purpose of the "dwell" message is to facilitate tool-tips and the like.

In a drag-and-drop operation the widget whose spot is being dragged grabs the focus and, probably, changes the sprite shape. By following the "gain focus" messages (which come to the drag widget instead of the newly entered widegt) it knows which other widget is the potential drop site and can respond appropriately.

Modal dialogues also grab the focus. Then they filter the messages so that only widgets with spots in the dialogue display ever get messages. There are several different ways to implement the filter.

Classical menus are more interesting. Like a modal dialogue they grab the focus and move around their option list but they also respond to "gain focus" messages in the other top level entries on the menu bar by sending them a message that changes the menu and passes on the grab. ANY click terminates the situation.

I favor giving up the classical menu construct and substituting a more conventional tree if we want to duplicate the functionality.

The double keyboard access methodology used with classical menus is one of the arguments against them. It is confusing. I think the keyboard "accelerators" should be equivalent to clicking on a corresponding spot. I have a suspicion that the keyboard will soon become an optional peripheral - comparable to a printer - used by people who do a lot of text entry and / or editing. Of course, at the same time the mouse may be replaced by a finger on a touch screen. But, like the keyboard, it will not die. Massive touching, even on a tablet, is too hard on the fingers and arms.

Re: I guess we'll start with menus ;)

by MasKalamDug on: Aug 30 2011

Score 50%

I have argued against classic menus but I think it would be counter-productive to make them impossible for a customizer to implement. This is about a detail I just noticed.

In the Ubuntu panel the trio of "Applications, Places and System" acts like a classic menu. But, unlike other menus the tooltips of other icons in the panel are active. The tooltips in the application are not. I don't know whether this is an accident or an intentional design feature.

Since the classical menu grabs the focus one would expect all tooltips to be disabled. But here I see entering and leaving messages being sent to icons that do not have the focus. So I would conclude the menu is passing on the entering and leaving messages to these other icons. It is not passing on clicks though because all clicks outside the expanded menu, as usual, close the menu.

One of our goals should be to make things happen in a uniform manner. Having two different menu behaviors should be avoided (not made impossible - just made difficult). My choice would be to disparage tooltips while a menu is active.

Re: Re: I guess we'll start with menus ;)

by user333 on: Aug 31 2011

Score 50%

Yes, consistency is extremely important. It would be a good idea to disable tool-tips when a menu is open.

Does anyone have any more ideas on how to make menus more usable?

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

What about FluiDE?

by user333 on: Jul 27 2011

Score 63%

Does FluiDE sound like a good name? I've checked and no one else has used the name, although it may be a French word.

As soon as we pick out a name I'll open a Google wiki site and/or Google group.

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

Re: What about FluiDE?

by Padster on: Jul 28 2011

Score 50%

Padster
editor
Home

Yep, it's French for "fluid". But sounds good to me.

101010
Reply to this

Re: Re: What about FluiDE?

by user333 on: Jul 28 2011

Score 50%

I should mention that naolloan came up with the name "Guipo." It stands for Graphic User Interface Paradigm Overhawl, but it also happens to be the name of a city in Honduras. I like the name a lot, but my fear is that it could get us into trouble. So far my research has been showing that the laws on this sort of thing are very unclear.

So should I open a google group under the name "FluiDE Project"? Although we aren't technically making a new DE, we need a name so we can at least start. Ubuntu didn't have a name for quite a while, so we don't have to either, but we at least need a temporary one. Then, once we are ready to promote it, we'll come up with a name.

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

Re: Re: Re: What about FluiDE?

by Padster on: Jul 30 2011

Score 50%

Padster
editor
Home

Good idea.

101010
Reply to this

A mockup

by user333 on: Jul 30 2011

Score 50%

Here is an idea I had:
http://opendesktop.org/content/show.php?content=144065

What would the disadvantages of this be?

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

Re: A mockup

by Padster on: Jul 30 2011

Score 50%

Padster
editor
Home

Disadvantages?

-Some might say that the side bar being there all the time and not really being full is a waste of space
-Also, I feel there should be some sort of toolbar for quick access to functions, sometimes it's just not quick enough to use that side bar

101010
Reply to this

Re: Re: A mockup

by user333 on: Jul 30 2011

Score 50%

Yes, I can see what you are saying. I can't deny the waste of space, but this design doesn't need a tool-bar, because relevant functions would be visible at all times. (You can see the Strips OS demo for a working model) Of course, a tool bar could always be added. The mock-up was just to give you the idea of how the sidebar would work.

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

Re: Re: Re: A mockup

by Padster on: Jul 30 2011

Score 50%

Padster
editor
Home

Okay, about the toolbar, I mean that it wouldn't be able to hold all the necessary functions in all cases. Like for GIMP, for example, there are tons of tools, and settings. But, yes, that could probably be added to the actual application, is that what you're saying?

101010
Reply to this

Re: Re: Re: Re: A mockup

by user333 on: Jul 30 2011

Score 50%

Yes ;)

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

Computer interfaces

by MasKalamDug on: Jul 30 2011

Score 50%

As I see it, there are different kinds of interfaces with different (apparent) needs - not to mention different users with different (apparent) desires. I'm willing to start deprecating the old menu bar but in a way I am more interested in the OS interface. One of my goals would be to get them both on the identical basis. Because different users use differently I would like to see the interface always driven by some design language of the HTML genera. That is something a relatively savvy user could redesign freely without any inside knowledge. HTML started that way but today I feel it way over scripted in most uses.

I'm far too lazy to do much actual coding so I wont offer any examples. At least not just now. I wont even offer any ideas in this post.

Re: Computer interfaces

by user333 on: Jul 30 2011

Score 50%

I'm glad you want to help out here =)

A HTML driven interface sounds appealing. Windows 8 will be based on it and the previews look great, and the ability to change things around quickly would be good. It would make it easy to experiment while are first starting out. I'm thinking, though it may be best to use clutter, cairo, opengl, or some other type of drawing toolkit. Of course a xml-type config file could be used to indirectly modify the layout of things. But then again, using a drawing toolkit would be a lot of work compared to HTML. Also, an HTML driven interface would run on older hardware, too.

Perhaps a custom HTML-type engine could be custom-made for the interface?

I fear, though, that letting the interface be too customizable would not allow tight integration or a smooth user experience.

Do you think that you could tell me more about your idea? I think it's great, since I already know HTML, and the features of HTML5 and CSS3 are amazing. The only thing I need to find out is how programs would be run inside a HTML document.

By the way, if you are interested in a highly customizable DE, this group is working on a totally new DE based on compiz, and they want it to be very customizable.
http://opendesktop.org/groups/?id=582

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

Abstract Interfaces

by MasKalamDug on: Jul 30 2011

Score 50%

Abstractly a computer interface isn't very complicated. The display is a set of pixels. There is a set of windows (not standard usage) and every pixel belongs to some window. There is a concept called focus. Most of the time there is a distinguished pixel called the focus pixel. The user can change the focus pixel, remove it from the interface and restore it to the interface. The window containing the focus pixel is the focus window. Each window has an associated widget (a software object). When the focus window changes the focus manager sends a leaving message to the widget of the old window and an entering message to the new widget. If the focus is being removed there is only a leaving message. If restored only an entering message. All the user input that is not grabbed earlier goes to the focus widget. As a luxury I would add a dwell message sent at longish (order of a second) intervals to help with things like tool-tips without putting a timer in every widget.

That's the interface. Its duty is to get the input to the widget. Of course, there is more - a window manager laying out the windows and all the widgets. And there are all those widgets (order of a hundred of them).

Re: Abstract Interfaces

by MasKalamDug on: Aug 26 2011

Score 50%

Somebody please tell me how to start a comment (if I ever knew I have forgotten) - all I can do now is reply. Or is that all I am supposed to be able to do?

I would like to define an application as a wrapper around a collection of objects. I would create its interface in the following steps:
1. Download a separate interface file
2. Translate that file from XML-like to DOM
3. Download a separate add-in file
4. Modify the DOM to accommodate the add-ins
5. Calculate sizes and locations
6. Display
My notion of the XML is that it has four kinds of elements - hbox, vbox, box (stacked) and spot. Boxes have members; spots don't. A spot can just be a passive display item but most will have a widget behind them to receive messages when the spot has focus. Every spot should also have at least one keyboard message.

The application gets the spot sizes from their widgets during steps 2 and 4 and runs up all the locations in step 5.

My model says there is an array of widgets parallel to the array of pixels and this would be the content of step 6 - go through the DOM and call each widget to both draw the spot image and set the corresponding widgets. Note that there is no requirement that every pixel in the spot go to the same widget or that the spot always correspond to the same widget.

Once the GUI is displayed the application is no longer needed and can be freed.

Re: Re: Abstract Interfaces

by user333 on: Aug 31 2011

Score 50%

To add a comment just click the "Add Comment" link on the bottom of the page.

Could you explain it a bit more? If your idea is for a widget toolkit, I don't think it would apply to this project. Otherwise, if it applies to the "shell," that is was we are going to work on ;) I think it would be best to use an existing widget toolkit, such as GTK. The main reason for this that we would be backed by a huge amount of developers, rather than struggling to make a decent library ourselves.

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: Abstract Interfaces

by MasKalamDug on: Sep 5 2011

Score 50%

If we want a lot of company we should go with HTML5. To me personally this would be OK because I want to hone my HTML5 skills - but it is not my main interest. I would rather spend my time on a project that, while it attracts little immediate attention, is eventually seen as pioneering and ahead of its times.

Re: Re: Re: Re: Abstract Interfaces

by user333 on: Sep 6 2011

Score 50%

I guess I would agree with you ;)

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

Google group and the possibility of HTML

by user333 on: Aug 2 2011

Score 50%

I opened a group here:
http://groups.google.com/group/fluide/

I chose to use fluiDE since Guipo might have got us in trouble.

One other thing:
Gtk 3.2 will support be default a HTML5 back-end. Although it is intended for use over networks, there is no reason it could not be used for window management. This means it could be possible to make at least a prototype interface that would actually work(only with Gtk3 apps, though). If we choose to stick to HTML5/CSS3/javascript for the "real thing", we will have to make some sort of hack so all windows can be controlled by HTML. If it was possible (though currently only firefox supports the HTML GDK back-end) a custom branch of webkit could be started, optimized for interfaces.

I'm guessing we will have to modify GTK, Webkit, or create are own packages to fill the gaps, but we may be able to create an interface with only HTML. Microsoft is doing it with Windows 8, and it looks like they did a good job (if they intended it for multimedia, not standard computer use).

One advantage of using HTML5 would be that the interface could be accessed remotely, so it could run on tablets, too. Also, with the new features CSS3 has, a very attractive interface could be made with very little code.

An example of a good HTML5 interface would be Google's presentation template:
http://code.google.com/p/html5slides/source/browse/trunk/template/index.html

While a very large javascript file is needed to use it, it is still impressive that no Flash was used.

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

Re: Google group and the possibility of HTML

by Padster on: Aug 3 2011

Score 50%

Padster
editor
Home

Yes, HMTL5 sounds good for an interface.

101010
Reply to this

Re: Re: Google group and the possibility of HTML

by MasKalamDug on: Aug 3 2011

Score 50%

I would say there are two choices open to people in a group with a name like this one - (1) go with HTML5 and work within its paradigm or (2) go for a more idealistic approach. Depends, I suppose, on one's needs. If one is trying to get end products out in the near future go with HTML5. If one is interested in the long range I feel HTML5 is not the answer.

There are several deficiencies. The one that bothers me the most is the lack of a clear packing discipline.

Packing is not that obscure. You just need four kinds of boxes (rectangular pieces of screen real estate). Two of them - vbox and hbox - are display containers and two - box and xbox - are not (as containers they work in z-order). The difference between box and xbox is that an xbox expands to fill available space. The boxes can be preented in XML style with attributes - like size - as needed.

I would start from a simple layout concept like the packing I have described and elaborate as needed to clarify issues and give the user what she wants.

Re: Re: Re: Google group and the possibility of HT

by user333 on: Aug 5 2011

Score 50%