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

The Function of a Menu

by MasKalamDug on: Nov 13 2011

Score 50%

My thinking continues to evolve. Now I imagine the menu of an application to be a script describing EVERYTHING the user can tell the application to do. For no better reason than that this script would be a valuable piece of documentation (try to get that information on any application you know of).

To insure that everything is covered I would require everything to go through the menu. For example keyboard shortcuts would be shortcuts into the menu - not into the application. Tool bar items would direct into the menu and so on.

Context menus would be build from extract lines of the main menu.

A simple key stroke in a text processor poses a bit of a problem. I propose treating it as a shortcut with an argument. The shortcut says "this is a text key stroke" and the argument is the key code. I already had shortcuts with arguments when I realized radio groups - the argument is which member of the group - and other value setting actions.

Value setting actions (like the number of spaces in tab indent) do not appear in the main menus of the example I have looked at. But they are clearly needed and must be considered as normal menu items.

More, of course, to follow.

Re: The Function of a Menu

by randallovelace on: Nov 13 2011

Score 50%

randallovela ce
Self Employed - Computer Repairs

One of the things that I'd like is menus from the mouse (as opposed to having to goto a button for menu)

Randal Lovelace
Reply to this

Re: Re: The Function of a Menu

by MasKalamDug on: Nov 13 2011

Score 50%

We need to get at the menu easily both ways. I think there is a real chance that the mouse will go away but none that the keyboard will. That is, the keyboard may become a frequent peripheral but the mouse might be gone completely (as in a tough screen).

There are a million ways to bring up the menu from the keyboard so lets not dwell on that. Finger on a touch screen has almost as many options. But I am not about to dismiss the mouse as a legacy device.

One way to use a mouse would be to ask it to click on some icon to get to the menu. The icon should be in the upper left corner so the menus open nicely.

Another approach would be having a sweep off the screen bring it up. That should work easily. Or spinning it in a tight circle.

We could even add "open full menu" to the context menu we get by right clicking.

At this point you can pretty much call your shots - what exactly would you prefer ?

Re: Re: Re: The Function of a Menu

by user333 on: Nov 13 2011

Score 50%

If you are asking on how the menu's interface should be activated, I would say that because it controls everything, it should be in a persistent spot, even if it is hidden some of the time, as opposed to a right-click menu. Since you need it all the time, it should be there all of the time. This makes the interface predictable, and would make it possible to follow fitts's law to allow easy access.

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: The Function of a Menu

by randallovelace on: Nov 14 2011

Score 50%

randallovela ce
Self Employed - Computer Repairs

I see where your heading on this - just watch a video about a plan that MS is working on to have no mouse or keyboard - and all touch screen (massive multi-touch actually - ie multiple users on same screen touching to do things).
I would then have to think that an edge motion may be the way to get to the menu - this way no matter what is open the movement would bring up the menu (since scroll bars tend to on right - assume left side for this).

This is just my thoughts -

Randal Lovelace
Reply to this

Re: Re: Re: The Function of a Menu

by novomente on: Nov 14 2011

Score 50%

novomente
Home

Menus. Well in thinking I returned to the basic question. Application can do a bunch of things. The question is: How to express application functionalities to a user and how user interacts with such applications?

Thinking a while about it I realized one thing. Let's say we have an office application. Text processor for example. Now we must know how to work with it. So we buy a book and learn, or we go to a learning course etc. If we know how to work with it, when we have some more problem or want to know advanced user interaction, we go to a Help and look for a solution. The Help usually show us a solution and explains to us step by step the way we can do it. Then we do it.

Thinking of it, we (our group) can merge application and Help together. In menus (which are customizable) we have the most frequent ways to work with applications. Then we have a search box, where we can type what we want to do. Then instead of that the application opens the Help, the application will open found solutions with descriptions and we choose one of it which applies to what we want. Then the started solution with further interaction (similar is for example a Wizard - opening wizard, new document wizard) do the things necessary to apply the solution.

Let's say we write a text in a text processor. Now we need it to be bold. We just select the text and press the bold button in a toolbar. The text changes to the bold text. This is common task. Now we want that every "homepage" word in a whole text will be a link to "http://www.FluiDE.org". In today applications we need to search every that word and then apply a link to it (probably we can make a macro)".

But with our application we just enter some text to the search box: >> revert every "homepage" into a link <<. The application starts to search for a solution. Then it finds a solution it is capable of. It opens a window where it asks to enter some informations it needs: Apply this solution to the selection or page or whole document (radio buttons). Which link to use (user types the link: "http://www.FluiDE.org"). Style of the links (underline, color). Etc. User can preview the changes and when he finishes the wizard (or the interaction with the wizard) and the application have all necessary information in order to apply the solution, user then can apply it.

We can then imagine a lot of things around this idea. We can make the solution to be included in the menus by user. We can have favorites or history of applied solutions. We can download a new add-in to the application (handling unknown solutions) from the Internet. We can imagine a solution-LEGO (some programmable functionalities). We can imagine some kind of artificial intelligence with solution-LEGO etc.

------

To the keyboard/mouse/touchscreen.
I don't think the mouse will completely go away. I don't think that touchscreen will be only the main one part of interaction. I think that there will be more interaction devices used. Speaking of today. Although we can fully control computer by only a keyboard, we also use mouse, because it is better and quick.

I cannot imagine when I go to a bank the officer will silently dictate my account number and name and amount of money to the computer. I can't imagine writing a book or programming code with a touchscreen or handwriting it with a stylus. I can't imagine controlling a computer only with a voice (unless with advanced artificial intelligence and perfect speech recognition). I cannot imagine playing today 3D first person shooter games with touch-screens. I can't imagine make an architecture plan or car design with a touchscreen or by voice.

Well I think that always it will be a set of specific devices that will be used to interact with computer. Today I took my 22" LCD to my hands and tried to imagine I work with it with touchscreen and stylus. First of all I realized the LCD resolution. I saw every pixel. Also the LCD shined to my face, what was inconvenient. This problem although can be solved soon.

Main problem with touchscreen is a touch itself. The finger touch is a big area. What about accurate drawing or selecting. With stylus it is possible. To use stylus and finger touch is good. But entering longer text is better (quicker and easier) with keyboard. Also I can't imagine 10 people in a room dictating a text to a computer. Just imagine that mess of voices with a radio station listened in a work place (can you concentrate in this environment?).

I can imagine the construction designer making a mechanical drawing by stylus and hand gestures. And the designer can stand in front of a big display instead of sitting in front of small LCD display. Problem would be probably the price (surely today). I can also imagine an artist drawing a picture with a chock (by stylus and touching a screen) - the artist draws lines with chock and then smudges the lines with fingers. I can also imagine the stylus to look like drawing brush or a stamp rectangle.

There is a lot of things we can imagine.

Yes the keyboard with dynamic LED keys is very good.

------

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

To be honest I would like to have tiled windows only. But they are inconvenient in todays applications. When I had a 17" display all I did to almost all opened applications was to maximize their window. Now when I have 22" display I unmaximized the windows and make them larger (overlapping). The large window I have centered because of not to have my head rotated constantly to one side. Sometimes when I have a window aside and work with it for a long time I change a position of my chair to have my look centered according to the window. When I have a big window I have small space at sides of desktop where when tiling windows is a place only to display a vertical menu or a sidebar. Thus on sides I have less frequent windows underlying the main working window so I can just press the sided window to have it in the top level.

Many times many years ago I was thinking of an application UI to be changeable according to a window size. Similar to HTML. I'm not talking about toolbar to show an arrow one side when being smaller than a window. I'm talking of changing an application's layout completely (in our project this can handle the UI-profiles).

The idea of Desktop Environment I had 2 years ago is a nice solution to tiling vs overlapping windows, to full workspace of overlapping windows, and to managing desktops. The solution I have is very nice and easy. Probably I make a mockup to demonstrate it.

Re: Re: Re: Re: The Function of a Menu

by randallovelace on: Nov 14 2011

Score 50%

randallovela ce
Self Employed - Computer Repairs

The video I saw - there was no keyboard or mouse - they could bring a keyboard up on screen and type - the other part I forgot to mention is that it was set like a drafting table and about 40" square.

Randal Lovelace
Reply to this

Re: Re: Re: Re: Re: The Function of a Menu

by MasKalamDug on: Nov 14 2011

Score 50%

I don't expect people who enter significant amounts of text to ever be happy with an on screen keyboard. I expect the keyboard to become an optional but frequent peripheral - like a printer. This means we must design our systems to work both ways - with and without.

This should be easy enough because a good implementation of an onscreen keyboard should be able to produce all the messages a keyboard does and vice versa.

In fact (actual keyboards are more complicated) all a keyboard does is emit an event with a one byte argument. Currently key down and key up are different events but we could treat them as a single event that alternates in meaning. The software can handle all the other details.

Re: Re: Re: Re: The Function of a Menu

by MasKalamDug on: Nov 16 2011

Score 50%

I think it would be premature to stop developing for the mouse. If it does go away not much will be lost. I think the lesson to be learn is that user peripherals are not a closed set. New ones may be invented at any moment. What we do must be able to plug-in a new peripheral at any time.

I am inclined to think of stylus touching and finger touching as two different things. Not only are fingers big and sloppy but also there are five of them and two hands. Apple is already using multiple fingers and talking about both hands.

I would like to able to subdivide my screen into sub-screens. This is an operating system function that resembles workspaces. That is I would like to split the visible screen and run each half as a workspace. The text lines even in an older monitor are too long for comfort. It is no accident that web designers use left and right sidebars to squeeze their main content to a readable width.

There is only a trivial difference between running multiple monitors and tiling your physical display into subscreens. All a screen is is a rectangular array of pixels - just like a window.

But, as I said these are OS functions - not GUI. The lesson for us would be that we must design for "screens" of arbitrary width and height. I believe it would be legal to admit we cannot display if the dimensions get too small.

It isn't easy to predict future technology. We have hang loose. I don't see any reason why big touch screens wont come down enough in price to be practical - but you never know.

Another thing to keep in mind is cases of real windowing. For example maps where the displayed picture only cuts out a rectangle from a much larger picture.

I am urging a model where the GUI itself is a scripted application with an easily cut off interface to an interior compiled (usually) application. The idea being to maximize the GUI flexibility.

Re: Re: Re: Re: Re: The Function of a Menu

by novomente on: Nov 17 2011

Score 50%

novomente
Home

Well said. My opinion on devices is same.

The sub-screens is a good idea and almost a need to the future desktops.

GUI as scripting application - exactly. The GUI is an independent part of an application, thus it is a independent application itself. Scripting? Yes, unless we find better solution.

What is a goal? Look at this video. It is one of the examples of what I meant by non-standardized 2D GUI (i.e. GUI-LEGO or another technique if we find better solution):

http://www.youtube.com/watch?feature=fvwp&NR=1&v=vaiRLpuwDZ0

Also try to imagine you have this display at your home/work and you use it with touch/stylus/other devices standing or sitting at it. The display may be placed on the moveable rotating-articular gear, so you can rotate and move the display as you wish.

This video of Microsoft Surface2 shows a brush-stylus in action (the physics drawing part of the video (starting at 1 minute and 50 seconds - 1:50s):

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

The prices of these displays will most probably go down in near future.

Re: Re: Re: Re: Re: Re: The Function of a Menu

by MasKalamDug on: Nov 18 2011

Score 50%

Unfortunately I don't have youtube (for techncial reasons too complicated to explain) so I can't watch your videos. So I can't comment.

There are two main reasons for insisting that the GUI be scripted - accommodating add-ins and allowing user customization. My concept of customization is, I think, rather extreme in that I would allow a knowledgeable user to completely rewrite the GUI. However it would be natural to "compile" the script for regular use and only re-compile when it changes.

Analysis of the Gedit Menu

by MasKalamDug on: Nov 14 2011

Score 50%

Gedit Menu

I think how to read this is obvious so I wont explain anything except the strings of letters in quotes - these are the keyboard accelerators that apply to the following list. A period means no accelerator (and usually corresponds to a separator - but not always.

The -indent- formatting seems to be a little broken and to introduce a blank line between each of my lines - but I think this is readable.





"FEVSTDH" 

    File "NO.SAR.WP.12345.CQ"

        New

        Open...

        ===

        Save

        Save As...

        Revert

        ===

        Print

        Print Preview

        ===

        recent1 see comment (1)

        recent2

        recent3

        recent4

        recent5

        ===

        Close

        Quit 

    Edit "UR.TCPD.A.E" 

        Undo

        Redo

        ===

        Cut

        Copy

        Paste

        Delete

        ===

        Select All

        === 

        Preferences 

    View "TSPB.F.H" 

        Toolbar

        Statusbar

        Side Pane

        Bottom Pane

        ===

        Fullscreen

        ===

        Highlight Mode 

            see comment (2) 

    Search "FXVI.R.C.L" 

        Find

        Find Next

        Find Previous

        Incremental Search...

        ===

        Replace...

        ===

        Clear Highlight

        ===

        Go to Line 

    Tools "CAL" 

        Check Spelling...

        Autocheck Spelling

        Set Language... 

    Documents "SC.PN.M."

        Save All

        Close All

        ===

        Previous Document

        Next Document

        ===

        Move to New Window

        === 

            tab list - see comment (3)

    Help "C....A" 

        Contents

        ===

        Get Help Online...

        Translate this Application...

        ===

        About 



The Toolbar and the Context Menus are supposed to point to the Base Menu



Toolbar 

    File / New

    File / Open

    segment 4 of File - see comment (4)

    File / Save

    ===

    Print

    ===

    Edit / Undo

    Edit / Redo

    ===

    Edit / Cut

    Edit / Copy

    Edit / Paste

    ===

    Search / Find

    Search / Replace 



Context Menu (in text area) "UR.TCPD.A.MI" 

    segment 1 of Edit

    ===

    segment 2 of Edit

    ===

    segment 3 of Edit     

    ===

    Input Methods 

        see comment (5) 

    Insert Unicode Control Character 

        see comment (6) 



Context Menu (in active tab area) "M.SA.P.C"

    Documents / Move to New Window

    ===

    File / Save

    File / Save As

    ===

    File / Print

    ===

    File / Close

Comments

(1) The names recent1 etc are the last five files edited - a mechanism must be designed to fill these slots correctly. If one of these is selected then File / Open is partially executed with the selected file.

(2) The contents of Highlight mode is a radio group with a large number of members displayed in a rather odd way.

(3) The tab list is the contents of the tab bar. Selecting a tab brings it up.

(4) A segment of a menu is the set of items between two separators in the menu

(5) The contents of Input Methods is a radio group with a modest number of members. This should be in the base menu and the context menu should point to it there

(6) The contents of Unicode Control Character is a list of such characters and selecting one inserts it into the text. I suppose that the list actually should be overtly in the menu but it seems too specialized for this presentation. This also should be in the base menu .

Re: Analysis of the Gedit Menu

by MasKalamDug on: Nov 16 2011

Score 50%

I have reduced the gedit interface between the GUI and the inner parts to a list of about 100 variables. About half of these are in the Print setup dialogue. So it looks to me like gedit is off base by including the Print feature. Upon thought it should be obvious that the Print capability should be a plug-in. Then people like me who do not have a printer would not plug it in.

This interface (which may be virtual) I am describing is a list of variables - most of them taking small integer values but some values must be pointers to strings. There are really two kinds of these variables - select and accept. A select variable means there is a list and one its members must be selected (radio groups). An accept variable requires the user to actually enter a value. Variables with only two values I separate out as toggles (check boxes) because they are usually not handled as selects.

One of the variable is called "command" and its value is the index of the actual command. For example, hitting the Cut icon in the tool bar might result in the interface change "command = 17". The GUI changes the value in the interface. The backend makes the cut and changes "command = 0" to indicate it is finished.

I visualize implementing the interface by imagining the interface variables in a list and then the GUI sends messages (calls functions 0r otherwise communicates) to the back end with two arguments - variable number and value - and the back end sends similar messages to the GUI.

The GUI design goal is to make all the necessary interface changes possible and the backend goal is to do everything and return useful information to the GUI.

The architecture of gedit is too messy for me to be sure I have detected everything but I see no reason why my select / accept model isn't universal. It still needs to be formalized.

Question About Usage

by MasKalamDug on: Nov 15 2011

Score 50%

I just discovered (by reading Gnome documentation) what lies under the Alt+Tab shortcut. If you haven't seen it I suggest you hit Alt+Tab (assuming you are using a Gnome system) and look.

What I see is a set of thumbnails - one for each running application. I hold the Alt key down and keep hitting Tab to move the selection from the thumbnails around cyclically. Then the thumbnail selected when I release the Alt becomes the active application.

Alt+Esc is supposed to be the same only with movement in the other direction. Nothing happens on my system with Alt+Esc. Ctrl+Alt+Tab is supposed to do something different but seems to be the same as Alt+Tab.

My question is - does anybody use this method of changing applications? It looks to me like once upon a time somebody did a lot of work to get this right. But it seems not to be maintained.

From my point-of-view selecting from the running applications is handled well by a simple "tab" system and this sort of elaboration is something we want to avoid - pretty as it is.

Re: Question About Usage

by Padster on: Nov 15 2011

Score 50%

Padster
editor
Home

I use it sometimes.

101010
Reply to this

Re: Question About Usage

by user333 on: Nov 15 2011

Score 50%

I've known about it for years, (it's on Windows, too) but I never use it unless my mouse isn't working.

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: Question About Usage

by MasKalamDug on: Nov 16 2011

Score 50%

Thanks for the info about Alt+Tab. I would never use it - but it's not evil.

Actually I should not be worrying about it. I am supposed to be determining what the GUI is working against - not how it works. I am supposed to say- if the GUI designer wants it - it's his privilege. Or their privilege if they are a committee .

Personally I would prefer enough customization capability that, having now discovered it, I could remove it.

Highlighting

by MasKalamDug on: Nov 23 2011

Score 50%

As gedit does things now, using GtkSourceView, the kind of highlighting is not under the GUI designer's direct control. It is my opinion that it should be and should, somehow, be a part of the GUI script. The same problem will arise in applications that use overt markup - like HTML browsers.

When I said GUI designer I mean the application's GUI. This is the problem theoretically solved by CSS - style sheets. The situation with gedit is a little simpler because a gedit text does not specify style - they are imposed on it. So gedit might ignore the cascading effect.

Hence the immediate question - gedit - could be solved by bring the highlighting styles out to where the GUI designer could specify them. But the larger problem of HTML etc. texts is not solved.

Exactly what should a GUI designer expect to have control over ?

Re: Highlighting

by user333 on: Nov 24 2011

Score 50%

When you are talking about Gedit, are you talking about creating an "overlay" interface that is separate from the actual program, but replaces the current GUI?

If this is the case, I think the GUI designer should be allowed to modify the layout and style of the controls, but not what the program displays. In the case of Gedit, the text should be rendered by the software itself, unmodified by the anything else.

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

by MasKalamDug on: Nov 24 2011

Score 50%

I am analyzing gedit in order to discover what I can about how real life programs of some complexity operate. I could have used any of many other programs but gedit was handy and I am interested in text processors. I don't have any real designs on gedit although I have generated a few ideas about improving it - most notably reducing print to a plug-in.

There are at least two different GUI designers involved here - for the OS GUI and for the application GUI and at least three competing opinions - both designer's and the user. This is the problem CSS solves(?). Whose opinion matters the most? I favor the user's opinion over the application's opinion over the OS's opinion. Not being myself a GUI designer I have no intuition about what GUI designers want/expect.

My interest here is how to decouple the back end of an application, where all the work is done, from as many details of the GUI as possible.

Gedit has forced me to recognize that there seem to be two parts of the GUI - the input part, where things like the mouse, keyboard, touch, etc. are handled and an output part where the computation results are displayed. I am now wrestling with problems like how much the GUI designer expects these two halves to coordinate.

The gedit output "GUI" is the WYSWHG display of the text (actually how WYSWYG is a serious question with gedit). Currently gedit's print facility does not reflect the display. Should we expect to divide gedit into two programs to accommodate, on the one hand, programmers, and, on the other, people who want a simple word processor? Syntax highlighting, for example, is not wanted by the word processing function - should it therefore be a plug-in?

It is easy to see how feature creep has distorted what should be simple applications. I want to relegate all new features to plug-in status.

Final (?) Summary

by MasKalamDug on: Dec 27 2011

Score 50%

MasKalamDug MasKalamDug
-

David Kleinecke 2

Last visit Nov 24 2011
0 Friends
2 Groups

More info
Send a message
Add as friend
Other contents

- -
I fear this discussion has come to an end. In my case I was thrown off course by the realization that plug-ins are just another way of looking at object inheritance. And that insight pushed me back into object theory and away from GUI's.

I am still deep into considering what objects really signify and all I can contribute now is the idea that the GUI is the proper place to register plug-ins.

What exactly a plug-in is seems a bit mysterious. I am inclined to identify it with the interface of additional methods added when one object type is derived from another.

The GUI of the older application object will work perfectly with the newer application object - providing I didn't override any of the older methods (or, if I did, harmlessly). But the older GUI cannot access the new interface. So a GUI for the newer object must integrate the new interface. In that case it should also handle "registering" the plug-in with the code.

Taking the idea a bit further I can look at the GUI itself as a kind of plug-in to the code object. But it really is more like a wrapper around the code object. Maybe the best approach would be two objects - code and GUI - acting as as a team.

But these are mere speculations I have no idea where they will go.

Re: Final (?) Summary

by user333 on: Dec 27 2011

Score 50%

While your model for the GUI/Core Program relationship would be ideal, I don't think that it is currently in the scope of the project, simply because we can't change existing programs without re-writing 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: Re: Final (?) Summary

by MasKalamDug on: Dec 27 2011

Score 50%

I was thinking long range. I have no reservations about forcing rewrites. My conclusion after years of supervising programmers was that every program should be re-written every couple of years. We were always too busy cleaning up after messes made twenty years ago to ever actually do that.

Re: Re: Re: Final (?) Summary

by user333 on: Dec 27 2011

Score 50%

Oh, ok. I agree with that ;)

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

When and how should we get started?

by user333 on: Jan 1 2012

Score 50%

I know some of this has been discussed before, but we REALLY need to decide on this stuff soon.

I think that it's important that we get some sort of result out of the project fairly quickly, even if just a super simple test. Otherwise, this whole discussion may never go anywhere.

We need a base system to work off of. What will it be like? Should we base it off of another DE, or create our own from scratch?

I know that the FreeDE project and Fluide may work together, but we'll have to see how that turns out. I personally think it would be best if FDE was a platform that had a separate front end. Due to the nature of our project, we can't make compromises if our goals are different from FDE, so we'll have to discuss all this with the FDE group members.

As far as graphics go, I still feel strongly that the interface should use web or web-like technologies, such as javascript, php, and css. This is much more modern than hard-coding things in C, and allows easy editing. Gnome3 and Windows 8 do this, and I think it is a really good idea.

Have a happy new year =)

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: When and how should we get started?

by Padster on: Jan 1 2012

Score 50%

Padster
editor
Home

I agree. Also: happy new year, too :)

101010
Reply to this

Re: When and how should we get started?

by MasKalamDug on: Jan 3 2012

Score 50%

And I also - Happy New Year. WE made it to 2012.

As to the project I fear I am not going to be much help. My biggest picture conclusion was that applications and web-pages should be aspects of the same thing. That would take me back in a circle to the idea of using HTML5 as the GUI. But HTML5 is a long way from what is actually needed. I am not going to be happy Until I thrash through all the issues I see and that may take me next to forever.

There is a trade off in language. An application can be hard-coded in any language (I prefer C) but if a piece of code is to be exposed to customization then a script should be used. There is no obvious choice of script but I favor Javascript mostly because of its tight relationship to HTML.

I'll stick around and comment from time to time but I think I am not mentally prepared to go to implementation yet.

Re: When and how should we get started?

by novomente on: Jan 24 2012

Score 50%

novomente
Home

Too late but anyway HAPPY NEW YEAR 2012 to everyone here.

I did not respond to this group for a long time. I have been busy with my study on University. I didn't think it would be so much time consuming and energy taking. Also I newly write some articles to linuxsoft Internet magazine (to make some money).

Now I must continue my study for next 14 days or more because I'm going to make final tests needed for continuing my study.

After that I hope I will have free time to read comments here and add some new things or ideas.

Shame is that we study JAVA language on university (not C language) so I stopped learning C and can't think in C scope about problems this group try to solve. But next half year I will someday start studying C language on university and will be more helpful here.

I read some last comments and the thought this group is going to end because of lack of talking here. Well this group is not going to end and I will continue to support it with the ideas and thoughts which, I believe, will push our minds and brains into new ideas, thoughts and talking.

Until then See You after 14 days :)

Re: Re: When and how should we get started?

by MasKalamDug on: Jan 24 2012

Score 50%

Good luck on your studies.

I have developed the opinion that the computer language one should learn is Javascript (not Java) even though I automatically use C (1990 version).

I hope this group does not die but we need a clearer vision of what we are doing. One thing I hope to do soon is take a good hard look at the Chrome OS - and perhaps advocate it as a starting point.

Re: Re: Re: When and how should we get started?

by user333 on: Jan 24 2012

Score 50%

Is Chrome OS flexible enough?

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: When and how should we get started?

by user333 on: Jan 24 2012

Score 50%