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

Some thoughts

by novomente on: Apr 11 2012

Score 63%

Few days ago I played with TinyCore - it is a Linux distribution of small size (13mb - yes "13 mega bytes"). It surprised me because into that 13mb it was possible to add graphical user interface and full linux. I was also delighted by its boot/shutdown timings. It is really fast. Many times i was thinking of an OS to boot very quickly. I hoped that future hardware would allow it (boot time = 1 - 3 seconds). But instead new versions of OSs implemented more features and the boot time took longer. This is one point.

Now I was thinking of our FluiDE DE to be as a mockup with windowing UI on text base screen. I intended that just for training and making the development easy while making mockup. I returned to MS-DOS applications and tried to think of some useful text base DE. These are very interesting thoughts. And suddenly my brain surprised me with some idea.

How about to create a DE on text based screen with full GNOME, KDE libraries support. It means to run GNOME/KDE etc applications on that text base screen DE without rewriting them. I think this is possible. But then my thoughts went more forward and I imagined that an application should be fully independent of the DE. I imagined that an application is written once and then only it's UI separated part would vary - ether for KDE or GNOME or text base DE or whatever. And now I'm starting to think of a technology, which makes the development of UI design/functionality possible. That's what we try to work on.

The goal of creating an application is to have that application available for all DEs (GNOME/KDE/XFCE/etc.) without rewriting the main part of it.

The second goal of better Operating System is to have such OS that is very very fast with small memory trace (probably without many features like nice look of the OS), allowing to give the hardware potential possibilities to applications and documents. It means that for example while the OS has not anti alias fonts, it allows the Office application to use them. This is the example of feature less OS and feature rich application model. Well I'm sure some project exists to handle this goal (maybe the "QNX" and others). I just imagine it to be very small and very fast like the TinyCore (but not as small as 13mb). That's why I also imagined the text base screen DE and full potential of it (for some type of usage).

Re: Some thoughts

by user333 on: Apr 11 2012

Score 50%

Yes, I've played with TinyCore! (and MicroCore, the smaller version, too) It's hard to belive, but I actually have a laptop that is to old to even run it xD But yes, I'd agree we need to make the DE fast and light, which would enable it to run on almost anything ;)

I've thought about cross-DE apps before, but you wrote it down very nicely :) The ideal progam, I think, would simply be a backend, kind of like a programming library. (I think we have brought this up before) Then, a interface could be created for it. Unfortuately, most programs don't work this, but we can encourage others to do this when they code. Maybe it could be forced. Python used strict rules, and as a result all code is styled the same. Maybe the DE should require certian programming practices, which would result in a perfectly uniform user experience. With this sort of model, a script could be used to control how applications were rendered, allowing easy customizing.

The text-based DE is interesting. Lots of ideas come to mind, one being that X applications could run in a low-resolution text-based screen. Or, it could simply mean a more complete linux shell. Either way, it would be a good way to prototype less graphics-dependend ideas.

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: Some thoughts

by MasKalamDug on: Apr 12 2012

Score 50%

Hi, I'm back. Got distracted and got called away on family business.

I believe that the fewer features an OS has the better. The only excuse for a new feature should be that it provides something that could not be done otherwise. The OS itself could then be supplemented by utility libraries.

Some people use the phrase Operating System to mean what I called the OS plus all of a collection of utilities. What I mean by the OS may be no more than a wrapper around the kernel.

I am still intrigued by interactive fiction. It is sort of the ultimate text application. Even if we get listening-talking computers the text versions and speech versions should be in exact correspondence (especially for the deaf).

What happens in an interactive fiction is simple. The computer displays some text. You respond. The computer replies and so on ad infinitum. This should be very easy to do - but it isn't. I can write a program (I use 1990 ANSI C) and compile it (GNU C) and run it in an unattractive console.

How does a GUI differ? I could (and people have) added pictures to what the computer presents. I could (and people have) changed the user text response from typed input to selection of a button from a presented list of alternatives. A classical GUI is only about one step further.

The additional step is doing other things with the mouse. I can think of three -

(1) dwelling to bring up tool tips and the like

(2) dragging and dropping

(3) picking out points in an image

I would think of text as a image and moving the cursor to a point in the text and clicking - in order to relocate the insertion caret - is an example of (3). But it is possible to do the same thing without the mouse. Even a point on a map can be located without a mouse. So maybe (3) doesn't count.

Likewise drag and drop.

To handle dwelling without a mouse I have to get more desperate but it can be done.

The key to GUI's seems to be that we have a two-dimensional array of pixels and a means to focus on one of these pixels and send that pixel a message. I have suggested that we maintain another two-dimensional array parallel to pixel array with the address where the message should be sent.

I observe that I really think the only way programs - all of them - should interface with a display is via a frame buffer. Is there any reason why this should be not assumed from the very beginning ?

Re: Re: Re: Some thoughts

by novomente on: Apr 15 2012

Score 50%

I think, David, that you are absolutely right with all you have said.

Firstly the interactive fiction - those text based games were very amusing and had many possibilities. More possibilities than their graphical today versions (Adventures point & click). I was thinking about the text base GUI the same way as you. I wanted to create a text base "kernel" while the GUI could implement it in various ways (with mouse or with keyboard; or with other devices).

The speech I named in TVc is only a future. I meant to develop text based UI with keyboard as a communication device and speech (sometime in the future) would only read the text from memory (synthesize) or use special program for speech recognition (to hear voice) which is converted in a text (and maybe some signs for stress, voice colour and vice versa) with which the OS then works.

Thus the goal I can think recently is only a text based system (without a speech). Interactive fiction is the part I would like to follow.

Secondly the two-dimensional array of pixels. I was talking (in our group) about a "scrollpad". I explained that it is not the point to point device for pixels. More it is a device to move from object to object on the screen (from button to button, from button to text filed, from text field to radio buttons - just to follow X and Y axis and the nearest object).

And that is exactly your proposed frame buffer. I think the mouse could be used the same way as "scrollpad". And both hardware devices - touchpad and mouse - have the ability to become a pixel to pixel pointing device for graphical reasons like image manipulation, 3D graphics etc. Both devices has the capability of using gestures. The touchpad hardware has the advantage that it could be a small or big touchscreen where various things can be displayed and by touching them with finger or with stylus can make appropriate action. The stylus also can be used as a pixel to pixel pointing device, great in handwriting, drawing and also 3D designing.

I think that the frame buffer is the good basis. But to be honest I didn't think of 3D GUI yet, what could be great in some future Human <-> Computer interaction. There are already some devices allowing interaction in a 3D world. The real best known is the XBOX Kinect. Such device (already sold to end users) proposed an era of 3D like devices and many more.

So I would like to think of such matter in our project - looking to a log term living age of it.

Re: Re: Some thoughts

by rakelleyjr on: May 25 2012

Score 50%

rakelleyjr

Text based is actually going one step too far for the core of the App and it impacts how you view the OS. Consider a spread sheet. For the application to truly be free, the UI would need to be completely separate from the App otherwise you would be undoing the text portion of the UI (think boards and such).

With regard to the OS side, one thought I have had on speed was why load everything before you can do anything? Imagine if the basics and networking were loaded. It would be nice to be able to bring up text based apps on a box (e-mail, a to-do list, schedule/calendar, etc.) and get some work done while waiting for the rest of the stuff to load. Better yet, when you need speed, be able to opt-out of loading the GUI and just have a text based windows environment (yes, I know I could "screen" through things, but that means keeping track of each screen/f-key in my head). This way I could do a bunch of system administration, view e-mail, chat, and browse at almost instant speed. In the current linux environment, even booting to text instead of gui still means the bulk of the windows still gets loaded. 5 boot options when they are so limiting is not enough.

Re: Re: Re: Some thoughts

by novomente on: May 31 2012

Score 50%

Hi and Welcome to the group. It is very nice to see some more person here :)

I have just read your comment. My English is still not perfect, so I had to read it three times and slowly with dictionary and I hope I understand it correctly. As I understand you are talking about booting Operating System. Fast load with text bases windowing system, where you can work in the meantime the GUI is loaded. With the option the GUI need not to be loaded. It sounds like interesting option.

I assume you have also some administrator skills (or Are you an experienced administrator professional?). Ok. In some discussion in my country (not English) I posted my dream when Operating System fully boots in 1 to 3 seconds. I got answers that the long booting is due to BIOS (which makes many checks) and then Linux optimizations (checks, loaded services and loading many mess of unoptimized system). I also got some answers on Operating Systems to load very fast.

For example linux distribution "Tiny Core" boots in VirtualBox at about 7 seconds (counted after pressing Run button). I also got this youtube video, where some guy boots Windows XP in VirtualBox. It is very interesting. I just note that someone commented the video as "When I watched the video, I almost fell off the chair, how fast it worked." - what speaks for itself - link on video follows:

http://youtu.be/H-LinhTC4jw

Some new talks about Microsoft being working on new operating system. It should remove Windows and it should be much smaller in size than Windows. I suppose the system is about virtualisation. But of course Microsoft specific implementation of monopol.

What do you think about fast full system booting? Is is worth to work on it? Or is it better to devote time to get lower UI loaded much faster with possibility to load GUI later?

DE - Taskbar, Groups and Desktops

by novomente on: Apr 13 2012

Score 50%

Before I answer David to the above comment, I would like to add the final part of the DE concept. I made an animation to describe the main functionality. The second part is about "Document Management" - this part is still not clear idea, but I hope some final version will come up. In the meantime let me present an animation with a first part, describing window and desktop management with Taskbar, Groups and Desktops:

http://novomente-activities.blogspot.com/2012/04/desktop-environment-taskbar-groups-and.html

Re: DE - Taskbar, Groups and Desktops

by user333 on: Apr 13 2012

Score 50%

This idea sounds great :) It's very similar to KDE's activities feature, but better, I think. The idea could be improved, mainly the UI layout, but the functionality is excellent. The idea of organizing apps into groups is my favorite part. I would do most of the organizing in a application manager, rather than the taskbar, though. Of course, grouping could be done in the "dock" also, and the interface you came up with for that looks cool!

One part that seems missing is tabs(multiple instances of applications). This should somehow be integrated with the application list, or in another way. There are lots of ways to do this, the two that come to mind are the Win7 way and the Opera collapsible tabs way.

I'll think about this more, and write again.

By the way, (I'm not putting you down, so please don't get mad) the GIF animation was hard to watch. It might be easier to follow it if it was simply a very long image that could be scrolled through. Just a suggestion for future mockups ;)

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: DE - Taskbar, Groups and Desktops

by novomente on: Apr 14 2012

Score 50%

I created the proposed long GIF with screenshots. It can be downloaded from the above linked Blog. The file is located in FluiDE files on SourceForge.net though (in "Discussion Files" folder).

Re: DE - Taskbar, Groups and Desktops

by MasKalamDug on: Apr 16 2012

Score 50%

I found the animation interesting and clarifying.

My concern is that it perhaps goes too far in supporting a single way to use the desktop. I would rather aim for something more generalized and customizable.

For example, I personally would prefer to start with a screen full of icons representing what applications and "documents" (meaning application instances) that I am currently using. Then I click on (or navigate with keys to) the one in want and it fills the screen.

I would dedicate one of the keys to bringing back the desktop. I personally have no use for more than one application instance at a time except at occasional moments where I would prefer to split the screen rather share one screen with two application instances.

But that is just the way I work. I know there are people whose screens always show a dozen or more different windows. I think a really useful new GUI should customize either way and other ways besides.

I think that I could say what I am describing as my personal way implies the task bar fills the entire screen and disappears when an application is selected.

By the way I seem to assume I am the only user of my machine (or at least of my screen). In any kind of a multi-user situation I think I talking about what happens the instant I establish my identity.

Re: Re: DE - Taskbar, Groups and Desktops

by novomente on: Apr 18 2012

Score 50%

I agree. The video shows only some desktop ideas I had 2 years ago. But I think we are working on more lower things which can be used as basis for many Desktop Environments. The Video shows just one.

I have another idea where Document is the main part of what should everything go around. I'm thinking of many applications to share one document space in memory. Each application holds its own specific version of the document and also provide the shared version to the shared RAM.

Although I had some practical ideas on how this could work, I'm still not sure of how this could work. I was also imagining the operating system is the only one application customizing the document, and real today applications are in that point of view only plugins to that operating system. With OS TVc and other DE parts it could work as a small or very big place for creating documents, fully customizable and extensable.

Both ways need something like shared memory manager - Dokument Manager or something, what holds the shared documents and manages the applications (plugins) access.

Thus the final DE should be handling such windows/documents management, where there is no taskbar for switching applications, but only to switch documents and working spaces for them.

That is one of the idea I had 2 years ago too.

General plan ideas

by user333 on: Apr 21 2012

Score 50%

Maybe for a general plan, we should stop worrying about the GUI. When we focus on that, we won't focus on really improving the way computer interaction works. (I'm very guilty of this, so I'm not putting anyone down) I think our goal should simply be to create the ideas that would go behind the GUI. For example, the idea that programs are simply puglins to the OS, doesn't need a GUI to make sense. Then, once we have the platform figured out, making a GUI that fits would be a very easy task.

I am just brainstorming, so feel free to say something if you don't agree with what I wrote here ;)

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: General plan ideas

by novomente on: Apr 23 2012

Score 50%

Yes I think we can concentrate on that. Few days ago I realized that you, Mike, have ideas about the DE itself and you are good in thinking in that point of view. So I will also try to think in that point of view and bring ideas about the DE. I think we both still bring newer ideas while the basis of DE goes forward.

For example recently I was thinking about small devices with small touch screen. I'm not talking about iPhone like devices. More I think of a "PSION 5mx" device (http://en.wikipedia.org/wiki/Psion_Series_5). It has a keyboard and touchscreen, able to be driven with a finger or stylus. Interesting is how the operating system works. And it is interesting to create DE for such device. I got some ideas for the PC DE while I played with the PSION. You can try it too. Here you can download the JAVA based emulator:

http://www.garethjmsaunders.co.uk/psion/emulator32_java.html

here are installation instructions (doesn't need to follow all of them):
http://www.garethjmsaunders.co.uk/psion/emulator32_install.html

here are instructions to run the Emulator:
http://www.andypryke.com/pub/Psion5mx

to start it (the link above) says:
install_derive:\epoc32\release\wins\rel\EPOC.EXE

install_drive is by default C:

This emulator runs on Windows and WINE perfectly.

Note: Although this software is called "emulator" it is only an SDK. But works like an emulator.

A clearer draft for the goal of the project

by user333 on: Jun 4 2012

Score 50%

I'm going to be a good example, and start using the SF forum. Click here to read my post: https://sourceforge.net/p/fluide/discussion/general/thread/4fab5dde/

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

Prototype

by user333 on: Sep 11 2012

Score 50%

https://sourceforge.net/p/fluide/blog/2012/09/some-progress-finally/

Read the blog post, then check out the prototype :)

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: Prototype

by MasKalamDug on: Sep 11 2012

Score 50%

Good Show. I downloaded the material on SourceForge but I haven't had time to examine it. I got discouraged because I couldn't do graphics as easily as I wanted. If there was a useable frame buffer out there I couldn't find it. I like the idea of using HTML5. Even if we have to run in a browser that better than not running at all.

Re: Re: Prototype

by user333 on: Sep 11 2012

Score 50%

I don't know about frame buffers, but we don't need a browser to run this. In fact, I made a small 10-line python script that allows it to run in a blank X-screen through webkit. In the future, we could even fork webkit or gecko and add more advanced features.

I need to find out if I can communicate between a application and the HTML interface. Obviously, even though HTML5 apps are great, they are no replacement for a real C application. I'm probably going to use a scripting language to receive signals that will be emitted by a program. So the next step from here is engineering how the applications will work.

I'm surprised by how ridiculously simple a desktop environment like this would be; it seems too good to be true. But, Windows 8 did it, and it works wonderfully. (I'm not talking about the terrible UX here, just the fact that it works)

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: Prototype

by novomente on: Sep 18 2012

Score 50%

I cant make it to work with latest browsers. I only see the BG image, clock and the topbar with only an Overview button. Nothing more. Can you pls, write what browser and what version you are using (where this could work)?

BTW last friday I passed the last of my half-year (semestral) exams on University. So I will have more time now to devote to FluiDE. Next half-year I also will study User Interfaces on University. So I would be more helpfull next year in this matter.

Re: Re: Re: Re: Prototype

by user333 on: Sep 19 2012

Score 50%

It works fine in either Chrome or Firefox. You will want it fullscreen so you can access the auto-hide menu on the right. Right now it doesn't do too much, but it does show that making a UI with HTML and CSS is possible.

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: Prototype

by Padster on: Sep 13 2012

Score 50%

Padster
editor
Home

That's pretty cool, looks promising :)

101010
Reply to this

Guidelines and Concepts

by novomente on: Sep 20 2012

Score 50%

Nice prototype. The interactivity makes the ideas included more clear. As playground it is perfect.

With HTML5, CSS3 and JavaScript there is a lot of things possible. The UI may look any way. It reminds me a time where applications had their own original look and usability. But at those times it was a problem, because users must learn every application to use.

The problem was solved over years with GUI toolkit (GUI components etc.). Such toolkit was library programmed for each operating system or each Desktop Environment.

It was also a solution to low memory of a desktop computer, where application shared the GUI toolkit in order to save memory footprint.

With HTML5 etc., there is similar problem to per application original look and usage. One can say it can be solved the similar way with programming a HTML, Javascript toolkit. Yes it is possible. But in the end many applications could be unsatisfied with such toolkit and their developers would choose to create their own toolkit. So I think that instead of making a toolkit or HTML/JavaScript API, there must be some guideline (concept) desription which most of application GUIs or most of GUI libraries or most HTML/JavaScript toolkits have to follow.

The guidelines only says how the desktop would look and function. Such thing is already done with Human Interface Guidelines ( http://en.wikipedia.org/wiki/Human_interface_guidelines ) which should the DE guideline stand on and freedesktop.org ( http://en.wikipedia.org/wiki/Freedesktop.org ) which is a project to make X-Window toolkits offer the same usage from a user's experience (such that applications using KDE toolkit would be very similar in usage as applications in GNOME and vice versa). The HTML/JavaScript guideline should play the same role as freedesktop.org.

The guideline must be not too complex in order to allow a wide range of applications to follow it. On the other hand there could be some more guidelines (concepts) for example a General User UI Concept, Administration Concept (concept for system administrators - terminal etc.), Graphics and multimedia concepts (like DTP, 3D creations, movie creations etc.), Server System Concept, and so on.

Maybe we should make difference between a "guideline" term and a "concept" term. The difference is that "guideline(s) is enough general to make wide variety of GUIs following it. The "concept" is more specific and describes for example a HTML/JavaScript "components", desktop, icons, functionality. The concept is only a document describing functionality and look of a toolkit, but it is not programmed toolkit. To explain it exactly lets say the GNOME is a coded toolkit. The GNOME concept is only a document describing the GNOME toolkit. With such description the GNOME developers exactly know what is a Gnome-Shell and what should it do and then they develop the Shell in C++.

So we can make a guideline and then a FluiDE-HTML/JavaScript concept (what is a document describing the FluiDE desktop) and developers can then code their own FluiDE toolkit exactly build for their single application. Then they need not to share any of HTML/JavaScript code among applications from different developer groups and all applications will look and function very similar.

Of course as well as web application frameworks are created (Joomla, Drupal etc.: http://en.wikipedia.org/wiki/Comparison_of_web_application_frameworks ) there could also be finished coded FluiDE toolkit or many other toolkits and frameworks shared among applications from wide range of developers.

The primary goal of a guideline is making usage over wide range of applications very similar (preventing a user to learn how to use every application) etc. The concept is a specific (but still anough general and open) to create UI (to say it exactly the GNOME concept exactly describes the GNOME DE and developers can create their own toolkits and frameworks which would look and behave exactly as a GNOME DE - so there could be per application specific GNOME DEs with or without sharing the framework).

Our task could be only to create very smart concept(s) which they really worth to follow. Plus code a FluiDE DE - as a real working example of what the concept is capable of. And if the FluiDE code will be perfectly written, it could be shared and meet with a success.

These are my thoughts today.

Re: Guidelines and Concepts

by Padster on: Sep 20 2012

Score 50%

Padster
editor
Home

Great idea, I like it :)

101010
Reply to this

Re: Guidelines and Concepts

by MasKalamDug on: Sep 22 2012

Score 50%

My goal remains simplicity. I fear this is already getting too complicated. My thinking is focussed elsewhwre. Here is an example of my present thoughts.

The underlying purpose of the interface is to present the user with a "display" of alternatives from which the user can select one.

If we use icons of about 24 by 24 pixels - which I think is appropriate for a touch screen - we can present up to around thousand alternatives on a desktop computer. This should be more than enough.

People can know more than a thousand icons (look at Chinese writing) but most people will not. So the first luxury we might add is the equivalent of tool tips. Tool tips don't work well on a touch screen (they tend be hidden by the hand) so I would add a bar at the top of the screen (other places on the screen also tend to be covered by the hand) where the tool tip is displayed. If you put you finger on an icon and leave it there for a while (dwell a bit) its text version is displayed in the status bar. To make the icon react you tap the icon (or dragi it).

Each icon reacts by sending a message to an object. Some of these objects will be utilities (like a file system) others will be applications.
Each of these other objects will have its own interface. Since it is generally agreed that interface consistency should be a design goal I want to make the basic interface no more than a case of a methodology any application (or utility) can use.

That boils down, at least conceptually, to where boot-up leaves a single icon which when conceptually tapped brings up what I called the interface and the interface itself is a rather dull utility.

The default interface would be a rectangular array of icons filling (potentially) the screen But everything should be customizable.

Re: Re: Guidelines and Concepts

by MasKalamDug on: Oct 20 2012

Score 50%

An addendum in honor of Windows 8.

I am now thinking of all GUI's as special cases of what I have decided to call a stasis (plural stases) - I hope I will be forgiven. A stasis is an array of pairs of a pixel value and an object identifier. I am think of everything being an object and "stasis" is really an object class and a GUI is an instance ot a stasis array along with a folding number (call it A). Then the stasis array corresponds to a rectangular array. The dimensions of the array are A by N/A where N is the length of the array.

The stasis code displays the stasis pixels on a screen and sends a message to the corresponding object if the pixel is "touched". That's all there is to a GUI.

I intend applications to begin by bringing up an instance of their own of the stasis class. In the object-oriented model I am using all the instances of an object class share the same code so more gUI's is almost free.

I expect somebody to come around asking about touch screen based GUI's. This is my answer to them. There are, of course, some more details to work out before anything is actually implemented.