gmane.comp.gnome.devel

The problem of GNOME3 is not the GNOME Shell

bugs — 2013-05-02T20:26:15

Hello!

Please don't take the following explanation as attack on you or your
work. What I want is helping you and GNOME!

The problem of GNOME3 is not the GNOME Shell, it is the constant removal
of features. To make this even more worse, the developers don't
communicate their plans and didn't react on well meant critic. Instead
the developers believe that the bloggers, the press or the users just
hate new things like the GNOME Shell[1].

GNOME 3.0 introduced a complete new user-interface and also some things
did't get ported from GNOME2. This is usual for major change and it is
also ususal that some users have problems with the new user-interface,
while others appreciated it.
The problem is that everyone expected that during the subsequent release
of 3.2, 3.4 and so on the missing parts get added. This happend for
GNOME2 and this happend with KDE4. But it didn't happend for GNOME3!

During the last releases important and loved features and options get
removed from GNOME, instead of added. And GNOME doesn't offer a big number
of
both, following it's own tradition. And this is still the case with
latest release of GNOME.

I thought about writing "this kind of mail" to mailing-list about a long
time now. The final reason was the removal of transparency from
gnome-terminal. Moreover the reaction of the developer itself[2]. Every
terminal offers nowadays real transparency, thanks to AIGLX and much of
hard work during the last decaded. Transparency is nice and also usefull.

I don't want attack this developer. I can just apologize that it hits him
(there are others)! I will send, in addition to this mail, a second mail
with a bunch of examples of what went wrong with GNOME3 and can made be
better. I decided to split this up, to focus on only on the general
problem and
possible solutions within this mail.
The second mail, with the examples, is build up on my personl opinions. In
the past other users thought in the same way, so I assume not to be alone.


Thank you for your patience and reading this. I want share my insights
with you and not tell you what you have to do. You have more time?
Please read on.


-----------------------------------------------------------------------
Problems:
* GNOME3 doesn't offer sane, well-known and loved features or removed
them
* Sometimes GNOME3 offers the desired feature, but it is hidden in dconf
and not much tested
* GNOME doesn't offer the users a clear plan what is considered for the
next release. There are mostly some blog posts about added, changed or
removed feature shortly before a final release. If this blog posts
launch a discussion, the developers can't or wouldn't accept others
ideas (it is natural do defend your work, especially after you put much
time in it).
* It is hard, nearly impossible, to change the mind of a developer via
bugzilla.
* GNOME3 doesn't offer a stable environment for users and other
developers

Solutions (Possible?):
* Every missing feature or option distract users, add important features
and make options easily available. Some people argue that "options" can
be overwhelming. That is valid, especially at the first contact.
Options, which are needed by advanced-users, should be placed under the
"Advanced-Menu". And a nice "Default-Button" can clean up even the worst
mess.
* Communicate clearly what you want to change and ask your users what
they want. Do this early in development and regulary! Clean up your wiki
and make the information publicy available. Provide an official forum
(not unofficial) where users can get in touch (mailing-lists, irc or
bugzilla are not the place). Start your own surveys instead of letting
do this others! Use gnome.org for showing your current ideas and work.
* Hear on your users! They want help you and most of them are
power-users with experience! Yep, power-users! This people regulary tell
the broad audience what is good or bad and support them.
* Instead of radically change existing things, why not fork the current
and offer it as alternative? Your alternative can become more mature and
may replace the old thing. It is better than split developers over
oppossing forks which doesn't work together, because everyone feels
misunderstood.
* Stability:
From the view-point of end-users addiditons or even sane changes are
okay, but removal of featueres is a not okay. In chase of companies and
public authorities this is a nogo criteria.

From the view-point of developers it is necessary to give them the
reason to trust in the environment of GNOME and GTK. They put much time,
work, and even money, in writing applications! This requires up to date
documentation and a stable API. The gtkmm-book is still at version
3.4[3] and the APIs for extensions[4] and theming[5] are not stable.

Define terse and clearly what direction GNOME takes: Laptop, Desktop,
Tablets and so on.

-----------------------------------------------------------------------

The End:

The dash, the overview, the efficient keyboard usage and the clean
notification-area with the seperation from the message-tray are just a
great approach. GTK3 looks awesome within GNOME3! It was brave to give
up the old concept of an "Desktop" and replace it. And it was the right
decision!

Peter

[1]
http://blogs.gnome.org/gnomg/2012/11/08/the-ups-and-downs-of-gnome-3/
[2] https://bugzilla.gnome.org/show_bug.cgi?id=698544#c1
[3] https://developer.gnome.org/gtkmm-tutorial/
[5]
http://blogs.gnome.org/mclasen/2013/03/18/is-your-gnome-shell-extension-ready-for-3-8/
[5] http://igurublog.wordpress.com/tag/gnome3/

The bunch of examples

bugs — 2013-05-02T20:26:25

I will keep this short! Not. I tried but failed! So please pick what
you are interested in. And don't take it personal. I can only apologize
for my own unfair and unpolite behaviour.

// nautilus - create empty file
Every file-browser does manage files, this includes the creation of
"empty files", not only "empty directories". This function was removed
with "3.6". Nautilus doens't fullfill the basic requirement of a
file-browser. This is wrong!
Instead users are forced to use the XDG-Directory "Templates" to create
a template for an empty file. But that is not possible, because for this
you need to create an empty file. This is weird!

Bug reports:
https://bugzilla.gnome.org/show_bug.cgi?id=324253
https://bugzilla.gnome.org/show_bug.cgi?id=676838
https://bugzilla.gnome.org/show_bug.cgi?id=683735
Screenshot:
http://i.imgur.com/CkkOlSL.png
Example:
Create an empty file "main.cpp", which can be double-clicked and edited
within Gedit with propper syntax-hightlighting.
Proposal: "Create empty file" should just be available, where "New
Folder" is available.

// nautilus - type-ahead-find
Common file-browsers offers the ability to use "type-ahead-find". Just
type the file-name you want and it will be selected instantly from the
current directory. Not shortcut required. It "finds" files, it doesn't
search (no disk i/o, no database). Type-Ahead-Find was even better
implemented in Nautilus than in Microsofts Explorer! Because you got a
box at right bottom were you see what you have typed. I also wondered
over years why this features did't worked reliable in Explorer, but in
Nautilus. Until sb. told me, that in Explorer a user have to type the
letters without a pause. The current search is stressful for the eyes,
file-icons "flicker" and dis(appearing) of icons.

Bug reports:
https://bugzilla.gnome.org/show_bug.cgi?id=679900
https://bugzilla.gnome.org/show_bug.cgi?id=680118

Screenshot:
http://i.imgur.com/Sat0lIL.png
Example:
Browser your files with "gtk-file-chooser". Type-Ahead-Find wasn't removed
from there!
Proposal: Bring back type-ahead-find and start the new search with "Ctrl
+F". It is, what every user expects.

Comment 17 from the first bug report:
feature is

Sadly this and the example above caused already forks, like Nemo and
Ubuntus decision to stay at Nautilus "3.4". Okay, I peculated split-pane.

// settings - suspend when lid closed
Most laptops go to Suspend-To-RAM (STR) when the LID is closed.
But a lot of users doesn't want this. While they want just protect the
screen and keyboard from dust, while the computer should still run (e.g.
compile something). Or while the want move to the next room with the
laptop, but don't want lost the wifi-connection (e.g xmpp, irc,
download...). Or while suspend and resume are not reliable.

Bug reports (?):
http://blogs.gnome.org/hughsie/2011/02/02/is-gnome-3-going-to-melt-your-laptop/
http://afaikblog.wordpress.com/2011/02/03/on-laptop-lids-and-power-settings/
http://worldofgnome.org/running-in-the-office-with-gnome/ # funny, but
not a fix
Screenshot: http://i.imgur.com/rCzf38y.png
Example:
Please search for this option in dconf! It's also gone! It followed the
typical "GNOME-Lifecycle": Removed from UI, broken in DCONF with
subsequent release (here 3.6), removed from GNOME entirely
Proposal:
A smart and logical grouping of options doesn't confuse but allows for
access to the important settings. The current ui already offers a good
solution. See the screenshot!
Logical grouping of options is the best solution! But I want to note
that a "Default-Button", "Advanced-Button" or a "Wrench-Menu" also
offers solutions. A novice users knows that "Advanced" is not a place
for him/her and "Default" could clean up the mess.

The rooted objections by the users doesn't changed the mind of the
developers, as can be seen on the links above.

The option for deciding what happens on LID-Close is relevant and this is
way it caused so much sadness on both sides. The aim to support new types
of devices should never be the reason to
restrict general usage. GNOME is only used on Desktop and Laptops, it is
not delivered on any tablet out-of-the-box and netbooks are already a
thing of
the past.
Moreover GNOME is not identified with a device. A computer is not an
applicane, like an iPhone.
Users are humans and are able to make decisions, it is their right to make
own decisions! There
are serveral obvious ways to suspend a computer and it is not necessary to
change the
configuration every time:

* Fn+F1-12 key for Suspend-To-RAM
* Command "systemctl suspend" or "pm-suspend" or a shell alias
* Item from the user-menu (hidden by default, press "Alt")
* After some idle time

Smart and important settings will not overwhelm users. If an user
obstrains from the decision,
the default will match. The "settings kill kittens"-argument is wrong. It
is possible that too many settings "frighten" kittens. Not offering the
important settings is
*killing* users!

At least it is very simple to point to others programs and daemons and
saying they do it wrong. Maybe GNOME is wrong? And even if GNOME is right,
sometimes it's
better to be smart than right.

// settings - background/wallpaper
The old dialog from 3.0 for wallpapers was removed. The new one force
the user to click on the current wallpaper and then offers some default
wallpapers, the screenshots from the ~ or ~/Pictures and some colors. It
removed the and obvious gtk-file-chooser dialog "Open" to add and
picture from a random location. It removed the options to
Zoom,Tile orStretch the picture, to make it fit. It stores the picture in
~/Pictures even it it the directory doesn't exist, because it was
deleted.

Bug reports: to lazy
Screenshots:
http://i.imgur.com/WsXEGnF.png # why the users have to click on this?
http://i.imgur.com/2Slx6li.jpg # why the users can't add a picture on
their own with file-chooser? why the users can't make the image fit
the screen, just think of 4:3, 16:9, 16:10, 21:9...
http://i.imgur.com/KE8PwQc.png # why are all the required options only
there? this also prevents creation of "~/Pictures"!
http://i.imgur.com/TUvhJkJ.png # original design of GNOME 3.0 at
bottom-right, by Allan Day (looks nice, works, obvious)
Example:
Delete the directory "Pictures", if you don't need it. My directory for
images is is "~/pictures", because I prefer lowercase letters for
directories (convention on UNIX). Open the
background-settings and drag(!) an image into it, which doesn't fit
perfectly to your screen. The directory "~/Pictures" is created and the
image get copied into it. You will be not able to make it fit without
dconf.
Proposal:
Don't created "~/Pictures", store the background-image into an
dot-directory. Like it was done before? Modifiying or
creating files in user-visible diretories is a bad idea. Add the "Open"
or "Add"-Button, it is hard to guess that drag&drop works. Add the
option to fit the image to screen. Remove the unnecessary step to "enter
the image settings" by clicking on the current background. Basically,
made it like it was before.

// XDG-Directories
GNOME creates a first-login the so-called XDG-Directories. Nice for
novice users! They just get in my way, so I delete them. That is really
okay. I just prefer other names (lowercase letters only in UNIX-fashion)
or doesn't use them at all. The problem is that GNOME 3.4 started to
rely on the existance of this directories and re-creates them!

Example:
"gnome-screenshot" tried to save screenshots "~/Pictures" in release
3.4, if "Pictures" doesn't exist it failed silently, but played the
shutter-sound and flashed the screen. This was fixed with 3.6, which
falls-back to "~".
The background-dialog re-creates "~/Pictures" and store the images
there, instead of using a hiddend directory like ".config",".cache" or
".gnome" or what contained stuff like that in the past.
And finally GNOME still creates "~/Desktop". And it re-created this also
sometimes! GNOME 3.0 removed the concept of a "Desktop" and finally
removed everything related with "3.8" but this directory gets created
anyway.
Proposal:
Don't rely *hard* on the XDG-Stuff. Please offer it! But don't enforce
it.

// eog
I always use Geeqie for viewing pictures. Mainly because EOG doesn't
display thumbnails in a vertical-sidebar, only horizontal. Also it
doesn't show the sidebar if no image is opened.
Proposal:
God damn! After ten years I found out the the option for vertical
thumbnails is hidden in dconf! Argh! Please, offer this kind of options
in the application UI. Also an UI should just show the thumbnails if no
image is selected, it just present what is in the current working-dir
(even if this is nothing). So the user has not to guess whether
thumnails are active and the UI is more "silent".

Fun fact: I know about one well know designer of GNOME, who doesn't like
horizontal scrolling.

// the removal of tabs
Of the last two years it has become a running-gag of mine, that GNOME
will remove tabs. From? Whatever! Tabs are the killer-feature of the
last decade and are used by text-editors, terminals, file- and
web-browsers! The tabs increased usability everywhere a lot of.
Mainly Windows-Explorer can't compete with any file-browser on Linux,
because the Explorer doesn't allow to use tabs! But this story is not
about Nautilus, it is about Epipany.

Epiphany feels much better with the last releases. Yep, the
application feels better and has becomse also faster! I think this is
the result of WebKit2 and the hard work of the developers of Epiphany!
Thank you! But this make me worried:
http://blogs.igalia.com/femorandeira/2013/01/29/a-few-more-ideas-for-web-navigation-and-a-talk-at-fosdem/

Kidding. You want remove tabs for this? Again, spell it loud:
"I will not remove important fetures. If I think I have a better
approach, I will *add* it but not *remove* something important!"

Tabs allow for instant switching with keyboard and mouse, while the user
can see what content is open in the other tabs. The approch from the
link above doesn't allow for both of this, is just makes much clicking
and searching necessary for the right thumbnail. Moreover it will not
fix the problem with "many open websites". A user will just have to search
for the thumbnail and maybe even scroll vertical for it. Honestly I
don't see the problem with many open websites. Many are many. I prefer
opening a second
browser-window (or another browser) in case of to many open tabs and
colleting the releated tabs in the windows, e.g. one for coding, one for
entertainment and so on. And bookmarks also help.
Proposal:
Add this new approch if desired! Really! As option in addition to tabs!
Moreover
take a look at the sidebar of Midori, it allows for opening bookmarks,
tabs, cookies and so on. Also the sidebar-approch allows for displaying
thumbnails in the sidebar of open tabs, much like a image-viewer does!
I've think I have
seen this on already within Firefox for Android (not sure).

// gnome-shell (new application launcher)
The keyboard-usage is awesome! But the mouse-usage has become worse with
"3.8". In former release we can use two button for "Overview" and
"Applications" at top-left corner, just missing "Zeitgeist" which was
not implemented. So an "Android-Style" icon was added to the dash. It is
not moveable and sits at the bottom. Also "Applications"
offers by default "Recent" not "All". But the icon indicates "All" and
this is what user expects anyway. The more recent applications will be
placed (in most cases) in the dash or executed with the keyboard. Also
"recent" could be empty - and it is on a fresh install.
Moreover the design seems to hide by default some important applications
in "sub-entries". This remembers on the bad behaviour of Windows-XP
which hides applications or menu-entries, which are less used. Why is
"gnome-terminal" less important than "sudoku". Why is "EOG" less
important than "Photos"?

Screenshot: http://i.imgur.com/2bmzAZQ.jpg

I marked the typicall mouse-way, it is a wide journey.
Proposal:
Make the "Applications" icon moveable, like all icons on the dash. Open
"All"
by default, not "Recent". Place the buttons for both at top-left of the
screen. Don't hidde some applications for no obvious reason.

// fonts
GNOME 3.2 offers an fancy new fonts-chooser. But we can't change the fonts
from
the user-settings. Why users are not allowed to change the fonts? The new
default-font
looks nice, but maybe the user want something other. A nice
"Default"-Button would also help
to reset the fonts.

The design of GNOME3 is great. The new font and theme rocks! It really
rocks! Taste is a subjectiv-value,
but "GTK3" looks always nice and Qt4 looks by default ugly. Sorry KDE! But
taste is subjective.

// support and stability
The problem is that GNOME only offers two support releases 3.x.1 and 3.x.2
on every major-release. The bug report below shows a bug
caused by GNOME or X11 in GNOME "3.4.2". It was fixed upstream but the
developers decide not to support the current release anymore.

At that time GNOME 3.6 wasn't used by any distribution. So the fix was
"waiting for the next major-release".

Bug reports:
https://bugzilla.gnome.org/show_bug.cgi?id=686102 # note: archlinux build
on stable-upstream and avoids custom patches
Proposal:
Supporting older code doesn't make fun, but it is necessary. Who doesn't
hate it? Is it better to "overlap" support between major-releases? Think
of
distributions, commercial users and public services.
Also why stick on two bugfix-releases only? A lot of GNOME-Projects
already doesn't care about this "limit".
If their are no dependencies, the project-developers would be free to
release bugfixes when necessary.

Why not untie certain projects from the release-cycle, e.g. Epiphany and
Evolution? This will give the developers the time to "getting things
done".
Obviously this doesn't match for the core applications,
like Nautilus, gnome-system-monitor or gnome-disks. But unnecessary tieing
seem like a drawback to me, not a benefit.

GNOME is tightly fit to a six-month cycle, especially with Ubuntu. At
least the later one will not matter anymore. If it ever did? I won't
jugdge this, but it seem to be very short and merely caused by "the
sync" with Ubuntu. Maybe a longer cycle would be better? This will
allow for collecting user-feedback (time lag between GNOME and
distributions) after the release, make proposals and drafts, talk with
user about the proposal and finally writing code. Will avoid "flying
blind".

// launch several applications at once from the dash with Ctrl+Left
Mouse Button
https://bugzilla.gnome.org/show_bug.cgi?id=686984#c49 # big thanks!
Well. I just want say thank you!
I'm also eager to see this added in future (waiting since 3.0 for this):
https://bugzilla.gnome.org/show_bug.cgi?id=644306

// clocks, wheater, documents, photos, contacts clocks # great! just
great! wheater # great, but like always it lacks the simple options:
switch from "Grad Fahrenheit" to "Grad Celcius" documents # i' dont get
the purpuse, it is not generic (nautilus) nor application specific
(evince, abiword, libreoffice) photos # i'dont get the purpuse, it is
not generic (nautilus) nor application specific like (geeqie, eog,
shotwell) contacs # good idea, evolution is to much for non-business!
but why i can import/export contacts? the application is in this state
a /dev/null or literally a dead-end for data. on the other side, i can
see the contacts from "contacts" in evolution but not the contacts i've
added in evolution in "contacts"?

Well. No I'm weird. To much contacts :D
Thank you for your patience. You must be crazy if you have read all of
this! Brave soul!

Peter

configure script requires intltool

Simon Kågedal Reimer — 2013-04-20T20:57:04

Hi,

I've written a simple program and based the build setup on the gnome-hello
Git repository [1]. However, when I do a "make dist" and run the configure
script on another computer, I get complaints that intltool is too old, or
that it doesn't exist:

    ./configure: line 11982: intltool-update: command not found
    checking for intltool >= 0.40.0...  found
    configure: error: Your intltool is too old.  You need intltool 0.40.0
or later.

The tarball should including any intltool things that are needed, shouldn't
it?

I get the same result with gnome-hello itself, doing:

    $ git clone git://git.gnome.org/gnome-hello
    $ cd gnome-hello
    $ ./autogen-sh
    $ make
    $ cp /usr/share/gnome-doc-utils/gnome-doc-utils.make .
    $ make dist

Gives me a package that won't build unless I have intltool installed. Is
this how it should be? Seems strange to me, since typically no build tools
like autoconf etc are required on the user computer. I was thinking the
intltool scripts should get bundled when I do "intltoolize" but it doesn't
do that.

I'm using autoconf 2.68, automake 1.11, intltool 0.50.2, gnome-common 3.1.0
on a Ubuntu 12.04 system.

Regards,
Simon Kågedal Reimer

[1] https://git.gnome.org/browse/gnome-hello/
_______________________________________________
gnome-devel-list mailing list
gnome-devel-list< at >gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-devel-list

Re: Questions about GClosure

Juan Rafael García Blanco — 2013-04-07T19:45:49

Hi,

Thank you Emmanuele, this makes things clearer. I've also read the glib-genmarshal page (https://developer.gnome.org/gobject/stable/glib-genmarshal.html) and I think I've understood this a bit more. 

Then a VOID__VOID callback has the form:
void func (gpointer data1, gpointer data2)

I understand that data2 == user_data (the same user_data passed in cclosure_new). But what is data1? I know that when connecting signals, the first argument of the callback is the object that emitted the signal. This is my question now: what is the parameter that is passed in closure_invoke, and that is different from user_data?

Thank you very much.

Regards,
Juan.

On Apr 7, 2013, at 12:10 PM, Emmanuele Bassi wrote:

Re: Questions about GClosure

Emmanuele Bassi — 2013-04-07T10:10:17

hi;

On Sunday, April 7, 2013, Juan Rafael García Blanco wrote:


you don't pass the user data when calling invoke(). the params[] array
contains only the arguments you specified in the marshaller. the user data
pointer that is then passed to the callback function is the one you used
when creating the GClosure.

a side note: I would not use GClosure, especially if you're concerned about
performance. the GValue boxing and unboxing can become a performance
liability in critical paths. you should use function pointers directly, and
if you need generic arguments, you can resort to varargs. if push come to
shove, using libffi directly is another option at your disposal.

ciao,
 Emmanuele.

Questions about GClosure

Juan Rafael García Blanco — 2013-04-07T09:04:14

Hello everybody,

I've a few questions about how closures should be used. I'm writing a GLib wrapper for OpenCL, and I feel the need to use callbacks. I'll try to explain what I don't understand about closures.

g_cclosure_new takes a pointer to user data as argument. This is passed to the callback in its last argument. But then, when I call g_closure_invoke() I need to pass a GValue array containing the arguments to the callback, and I guess user_data is included here. I see this as a redundant action, so my guess is I've got something wrong. I hope you can clarify this a little bit for me. I'll appreciate it.

Thank you very much in advance.

Regards,
Juan.

Re: GArray conversion

kuldeep dhaka — 2013-04-05T10:48:13

while working on my project,
i again got a problem related to this.

my array count N*2 elements

so i want a natural array of array[N][2] , how can i accomplish this?

i tried to use "nat_array = (type **)g_array_free(garr, FALSE)" but this
time , it cast a 1D array to 2D array, and if accessed the 1D using 2D
method it will (and is) cause segment fault.

generalized description,
if garray contained M*N
then we need an natural array of n_arr[M][N]

description of my project.
it takes input from command line $<program> x,y x,y x,y ....
i dont want it to take input the number of x,y
example: not this --> $<program> N x,y x,y x,y ....

it can be accomplished by reversing the method of storage,
storing x's & y's in different Garray and then dump the g_array_free the
natural pointer to n_arra[2]
im not much interested in implementing this one.

using va_list this can accomplished , which zero as ending, to
g_array_natural.

also, if i accept N , i can solve the problem easily.
i would like to take your opinions, shall i input N also.

hope you all understood what i mean. :)

On Thu, Apr 4, 2013 at 9:36 PM, Christophe Fergeau <teuf< at >gnome.org> wrote:

Re: GArray conversion

Christophe Fergeau — 2013-04-04T16:06:38

Hey Kuldeep,

2013/4/4 kuldeep dhaka <kuldeepdhaka9< at >gmail.com>:

I think
natural_array = (gdouble*)g_array_free(arr, FALSE);
would do what you are asking for.

Christophe

GArray conversion

kuldeep dhaka — 2013-04-04T15:08:02

hello guys,
i think a function like this could be useful.

c-code:

GArray * arr;
gdouble * natural_array;
unsigned int size;

arr = g_array_new (FALSE, FALSE, sizeof (gdouble));

... add values to GArray ....

<store the size of garray in size var>

natural_array = g_array_natural(arr, sizeof(double));

#gnome, Juhaz : if you're talking about GArray, the accessor function isn't
a function but macro, so there's no performance penalty to it.

atleast still the function can be useful when we want to make things simple
and when garray functionality is no longer required.

Re: GSOC Idea

Michael Mercier — 2013-03-17T19:15:48

Hello,

I thinks it's a really good idea to improve terminal work with clever and recent tools.
All the points you are giving are relevant. Maybe a field that show physical and memory
location could be added (like http://byobu.co/ do).

I want to notice that I use zsh with the grml config and it does a lot of the things you mention.
It could inspire your project...

Good luck with your project and please keep us in the loop!

Michael
_______________________________________________
gnome-devel-list mailing list
gnome-devel-list< at >gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-devel-list

GSOC Idea

Rajath Shashidhara — 2013-03-15T04:17:13

Hello,


 I aspire to participate in this year's Google Summer of Code. I propose
the idea of making a new intelligent and interactive terminal emulator with
rich GUI features. These are some of the improvements that I propose to
replace the current gnome-terminal:

   1.

         Seperate fields for Input and Output:

 Input and output are clearly seperated from each other in different text
fields.


 2. Flags associated with various terminal commands are shown as a checkbox
group with a brief description about the use of each flag:

   It reduces the effort in finding out the various flags associated with a
               command on man page and then executing the code. When a
command is typed
               the flag list automatically can be pops up a checklist
and recently used
               flags are automatically checked.

 3. Selective copy of recently used commands:

   A recently executed command can be selectively copied.

 e.g.: Previously executed command is:

gcc abc.c -lm -o abc.o

can be selectively copied as

gcc abc.c -o abc.o

 4. Intelligent selection of files with auto-correct feature:

   A filebrowser is shown in the side-bar when typing a file name in a
            command to guide the user in selecting the correct file.
By chance, the
            typed file is not found at the given location, the
terminal produces a list
            of best matches to the file in the nearby locations or
files of similar
            name.


 5. Storing startup commands:

A list of startup commands can be stored can be stored. These commands are

automatically executed at the start of terminal.


   1.

         Search manual pages for a particular keyword:

 A particular word can be searched from the 'man' pages for all the
available commands/a particular command. This way the user can find the
commands related to a particular keyword.

 7. Warning dialogs:

dialogs to alert the user a file is being deleted/super user permission is
required to execute a particular program/any other alert/warning/error
issued by the terminal. This makes the terminal more interactive.



   1.

         Auto-Corrections for mis-typed commands:

         When a particular command executed is not available. A close match
         is searched. If no close match is found, the repositories are
checked for
         any close match. If found the matches are displayed. If not
installed, it
         is automatically installed without the user having to type
sudo apt-get
         install or equivalent of it in other linux distributions. If a similar
         command has been successfully executed before with different flags are
         variables, they are suggested.

Tools used to make these : PyGTK+

RICH GUI elements like dialogs, popups, drop-down menus,etc. will be used
to make the interface intuitive.

These are a few additions which I suggest to make terminal user-friendly.
Please suggest your views and suggestions about my idea.


-RAJATH S
Birla Institute of Technology and Science, Pilani Campus,
Pilani,
Rajasthan,
India
_______________________________________________
gnome-devel-list mailing list
gnome-devel-list< at >gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-devel-list

Name for sanad is merged with the last name value.

Tae Wong — 2013-02-22T05:26:15

Smart quotation marks become question marks with the mail provider,
for example last name’s value becomes last name?s value. You don’t
want your messages automatically rejected; although you’re not working
with GNOME. Read the Foundation Members page in GNOME and check if
sanad is merged with the last name value. You’re not developing for
GNOME.
_______________________________________________
gnome-devel-list mailing list
gnome-devel-list< at >gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-devel-list

Gnome-system-monitor - rounded graphs: a proof of concept

jordan — 2012-12-20T21:32:48

Hi,

Recently, I have been hacking on the gnome-system-monitor code, to
implement some aesthetic changes, for things that have long bothered
me about GSM. the big change that i have been working on - adding
rounded corners to the graphs (rather than having rectangles that
don't even use the same background as the notebook bg color in many
cases (ie: you end up with notebook/graph colors not matching on many
themes + it just looks (imho) a bit ugly / unrefined). So even though
i know very little about cairo (and although, i hack on code from time
to time - wouldn't consider myself to be a 'programmer'), i decided to
see what i could do :) I ended up with decent success, to the point i
would at least think my code produces a good demo/prototype/proof of
concept.

Here is my version of gnome-system-monitor (picture);
http://postimage.org/image/c1k6h723d/

and a quick video, just showing the resizing working correctly;
http://www.youtube.com/watch?v=QgeAeCayw7Q

NOTE: pay no attention to the hardcoded background colors (that is
just to have it match my theme), nor the 2 pixel lines (again, a
personal preference).  What i think is important here is that it looks
cleaner than the boxy-upstream version (again,imo). Like i said, im
not much of a programmer, so i borrowed some existing cairo code and
modified it so that the rounded rectangles would resize properly
(allocation.width/height). The rounded rectangles are actually drawn
inside of the rectangles/graphs and the (outer) rectangle is blended
into my notebook background (cairo ... rgba with 0.97, 0.97, 0.97,
0.97), making it invisible (although i need a proper solution here
that doesn't require hardcoding the color for it to work on all
themes, correctly - gtk_normal_window often looks bad - I've tested
across many themes. ie: notebook bg_color and gtk_normal_window rarely
actually match well).

all of my changes occur in load-graph.cpp; http://pastebin.com/W1FEUVNT

You can just use diff to see my changes (some of which are irrelevant
to rounded graphs). the main changes start at line 106 ~ with a few
modifications around line 90-95 to get the outer graph rectangles to
be invisible.

I'm not looking for this code to be merged upstream (it's not clean
enough, nor implemented properly), but i thought it might be nice to
share, regardless - since even though it is a minor detail - i think
it does look better (and if implemented properly, would be worth
considering). I will probably have a stab at reworking it and trying
to get it to have no hardcoded color hacks, then possibly make a patch
to submit - but if any of you think this might be worthwhile - i am
betting you could do it in 5 to 10 minutes (as opposed to me not
really knowing what i am doing..lol)

cheerz

PS: i should also mention that using black as the graph bg color -
highlights what seems to be a bug in Gnome 3.6, where the graph
flickers when moving back and fourth from other windows, after GSM has
been running for 5 to 10 minutes ~ this happens in the upstream
version too, it's just less noticable in a theme like adwaita where it
is white on white. (sorry, i wanted to make a screencast - but
couldn't capture it properly, as it flickers for a split second - but
it does look abd when it happens ... and i believe it is a regression
- ie: i never saw it in any earlier release of gnome - and i've
modified the graph colors to be black in the past).

Re: glib gio usage of the library outside of GNOME

Alexander Larsson — 2012-11-02T09:05:21

On ons, 2012-10-24 at 18:41 +0200, Michael Weimann wrote:

Inside gio there is a default implementation of GVolumeMonitor that is
very much a "traditional unix" style thing. It only looks at /etc/mtab
and /etc/fstab and does some magic matching to guess what is what. This
is clearly not going to get you everything that a "modern" desktop
needs. For instance, there is no concept of a "drive" in such a setup
(for unix, an entry in mtab is a mount, and an entry in fstab is a
volume), nor do we know much about the properties of the volumes.

In order to get more information from the volume monitior you need:

a) gvfs installed, with at least one native volume monitor
implementation (and its dependencies) built. We currently ship a hal
one, a gnome-disk-utils one and a udisk2 one.
b) A session dbus running. This is on by default in an X session, but
you can launch your own with dbus-launch in a terminal if you want.

Re: Coordination between developers in the GNOME project

David Gomes — 2012-11-01T20:54:24

This is the most active mailing list, but don't forget to check on IRC
because I believe there are more developers there.

On Thu, Nov 1, 2012 at 8:53 PM, Tengy Td <duret.tanguy< at >gmail.com> wrote:

Re: Coordination between developers in the GNOME project

David Gomes — 2012-11-01T20:49:40

Many Gnome developers are under the age of 18, why not allow such ages?

Also, for some reason I think this mailing list isn't very active.

On Thu, Nov 1, 2012 at 8:39 PM, Tengy Td <duret.tanguy< at >gmail.com> wrote:

Coordination between developers in the GNOME project

Tengy Td — 2012-11-01T20:39:25

Hello,


I am a French student and I am currently realizing my final thesis in the
field of Free/libre open source software.

It would be a great help for me if you could answer a short online survey
(it should take approximately 5 minutes).

 This survey is designed to reach a better understanding of the cooperation
and coordination between developers in Free/libre open source projects.

There is no right or wrong answers, therefore, feel free to answer
spontaneously and to skip the questions you feel you do not want to answer.

The link to the survey is: http://bit.ly/U1BjTh


I would like to remind you that the participation is absolutely anonymous
and voluntary, and you can quit it at any time. Your answers will be
strictly confidential and will be used only for research purpose (no
commercial use of any information you provided).



If you find this survey interesting, you are welcome to share it with other
developers!


If you want to add something, or if you need further information about this
survey, feel free to contact me at: d <tanguy.duret< at >gmx.fr>
uret.tanguy< at >gmail.com

Thank you in advance for your cooperation and your enthusiasm! :)


Tanguy Duret
_______________________________________________
gnome-devel-list mailing list
gnome-devel-list< at >gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-devel-list

Re: How to prevent gnome-settings-daemon from touching keyboardconfiguration at all?

Chow Loong Jin — 2012-10-31T13:21:38

On 31/10/2012 20:27, Vasily Khoruzhick wrote:

It's a per-user setting. As for removing the keyboard plugin, that's also quite
possible without recompiling -- just remove
/usr/lib/gnome-settings-daemon-3.0/libkeyboard.so and
/usr/lib/gnome-settings-daemon-3.0/keyboard.gnome-settings-plugin.


P.S. Please don't send me a direct mail when you reply -- I read this list
through gmane.

Re: How to prevent gnome-settings-daemon from touching keyboardconfiguration at all?

Vasily Khoruzhick — 2012-10-31T12:27:41

On Wed, Oct 31, 2012 at 3:14 PM, Chow Loong Jin <hyperair< at >debian.org> wrote:


Layout switch key specified in xorg.conf still is not working. Is this
setting global or per-user?

I've recompiled gnome-settings-daemon without keyboard plugin at all,
and settings from xorg.conf have expected
effect, but I prefer less invasive changes.

Regards
Vasily

Re: How to prevent gnome-settings-daemon from touching keyboardconfiguration at all?

Chow Loong Jin — 2012-10-31T12:14:23

On 31/10/2012 18:55, Vasily Khoruzhick wrote:


I haven't tested to see if this works, but try disabling the keyboard plugin in
gnome-settings-daemon:

$ gsettings set org.gnome.settings-daemon.plugins.keyboard active false

glib gio usage of the library outside of GNOME

Michael Weimann — 2012-10-24T16:41:27

Hello,

I'm curently working with the gio library. Especially with the 
GVolumeMonitor. My problem ist, that the GVolumeMonitor doesn't seem to 
work outside of GNOME (e.g. on a terminal only).

I created a test code:
g_type_init();
GVolumeMonitor *vmon = g_volume_monitor_get();
GList *drives = g_volume_monitor_get_connected_drives(vmon);
printf("DRIVES: %p\n", drives);

Inside of GNOME I receive a valid entry for drives, outside nil.

Is there any special thing, e.g. initialize gio, to get this working?

Thanks and Greetings
Michael Weimann