I had an idea today, about notifyd. From time to time, I'd like to have a way to ignore all notifications coming (like, when I do a presentation, or show something on my screen to someone). I could kill notifyd, but it's not really userfriendly, so I thought it'd be nice something like a quiet mode.
When in this mode, notifyd would store the notification and not display them, maybe showing the number in an icon in systray. When clicking on that icons, notification would be displayed (in a convenient way, because if there are too many notifications, they can't be displayed at once in a usual way).
That means there'd be a need for a systray (or plugin) integration, so one can chose to (de)activate the quiet mode, see the number of waiting notifications, an have a way to acknowledge them.
Though, some notifications don't have the same priority/urgency, for example "urgent" ones may be still displayed, "standard" ones discarded and "priority" ones stored.
What do you think?
It seems like it'd be useful, but a having a systray icon for this sounds excessive and a waste of space.
I agree about a waste of space in the sys-tray. But you could have an option in the regular preferences dialog (I don't see people switching back and forth too often) and only show the tray icon when you are in "presentation mode". That was it is only using space when you need it.
*** Bug 10370 has been marked as a duplicate of this bug. ***
That is such a LAME answer.....
I have not done much coding - but I CAN do it.
It's about time that you started to point people in the direction of HOW to code, and HOW to make the changes, instead of going, "Duplicate of, Duplicate of, duplicate of" - can't be fixed until...
We are all volunteers..... time.... "
So where is the BOOK on CODING, in this (computer) language?
Start INCLUDING people in the FIX UP process, start teaching them, start posting links to the resources, so that people can change what needs to be changed.
And stop locking people into stupid shit that has NO options - like NO on / off switch.
Or things like the contrast in the color schemes that produce all the elements of the windows that are 1/2 a shade of the same color gray.
Or window's can only be dragged IF you get the mouse within 1 pixel of the border line.....
You know there is some really, really, really stupid shit that gets done to people - and it makes it a trauma to use the interface, and 10,000 complaints later - no one has fixed it.
And the only thing you can do is say, "Resolved - duplicate of - All volunteers - no enough time - might fix eventually - one day"
So get off the bloody finger in the arse and start TRAINING people how to CODE and put in LINKS to the very best resources, on HOW to fix the problem.
Discalimer, I am not an XFCE dev, these opinions are my own.
> That is such a LAME answer.....
It is not a lame answer, it is the truth. This bug has already been reported and you are free to add your comments in the original. It is difficult to keep track of things when they are spread across many bugs.
> I have not done much coding - but I CAN do it.
Great! Feel free to submit a patch. If you are polite I'm sure you can also get lots of help along the way.
> It's about time that you started to point people in the direction of HOW to code, and HOW to make the changes, instead of going, "Duplicate of, Duplicate of, duplicate of" - can't be fixed until...
Here are the sources http://git.xfce.org/apps/xfce4-notifyd/tree/, they are written in C. Use your search engine of choice to find a good C tutorial, you can do it yourself, I promise. (this is the one I learned from, it is quite good http://www.iu.hio.no/~mark/CTutorial/CTutorial.html)
> We are all volunteers..... time.... "
I'm sorry but this is the plain truth, the devs have families to feed and things to do, they work on this project because they enjoy it. If you want someone to work on what you want feel free to make it worth their time. Maybe they would accept payment for a feature, screaming at them probably won't make them want to help you out.
> Start INCLUDING people in the FIX UP process, start teaching them, start posting links to the resources, so that people can change what needs to be changed.
The basic links are available, the sources and commit log. If you want something specific you need to ask (politely), we can't read your mind.
> And stop locking people into stupid shit that has NO options - like NO on / off switch.
> So get off the bloody finger in the arse and start TRAINING people how to CODE and put in LINKS to the very best resources, on HOW to fix the problem.
We can't read you mind, ask for suggestions on how to code. Be POLITE! You would be surprised how happy to help this community is. Don't start saying bad things because they didn't fix the bug you wanted fixed. This bug only has 2 CCs, there are many other bugs that have more "interest". If you would like to help code there are many great tutorials, I'm sure another contributer would be appreciated.
This is an improvement.
I'd like to see a standard 2 line prefix added to all initial responses.
1. The location of the code in the filing system.
2. The programm to view the code with.
3. The type of programmming language - and link/s to the turorials on how to write the code / commands.
4. HOW the edits interact with other aspects of the entire or relevant parts of the operating system.
5. How to run and test the modified code.
6. And how to "release it / upload it" for further evaluation.
I absolutely hate microsoft and I will do anything to keep that incompetently written nazi spyware out of my life and off my systems.
I'd like to have a comprehensive Nautilus based version of XFCE...
I will start on the coding path for linux, by OFFERING a choice of notifications or NOT.
Sometimes they are actually useful but having HUGE BLACK SPACES taking up screen space on my netbook - telling me stuff that I already know - for the 10,000th time drives me nuts.
It's like having flies in my eyes.
> This is an improvement.
It's amazing what happens when you ask.
> I'd like to see a standard 2 line prefix added to all initial responses.
Personally I think this is a little excessive. On the homepage there is a "Getting Involved" link, and there are detailed building instructions in the docs. I did notice that the developer section in getting involved didn't have a link to more docs, maybe that should be added.
> 1. The location of the code in the filing system.
This is described in the building page I mentioned earlier. I have also already linked it, here it is again http://git.xfce.org/apps/xfce4-notifyd/.
> 2. The programm to view the code with.
Any text editor. Try gedit or geany. This will be covered in any programming tutorial you read.
> 3. The type of programmming language - and link/s to the turorials on how to write the code / commands.
AFAIK, all of xfce is in C. There are literally thousands of C tutorials around.
> 4. HOW the edits interact with other aspects of the entire or relevant parts of the operating system.
This is a very difficult question to answer. For this change you are modifying xfce4-notifyd. But depending on what changes are made there may be various interactions with different parts of the DE.
> 5. How to run and test the modified code.
See the "building" link.
> 6. And how to "release it / upload it" for further evaluation.
I believe the preferred method is submitting a patch to this tracker. Look up how to create patches and upload the patch to this issue. Then it can be reviewed and if a maintainer likes it it will be applied.
While this is the older bugreport, the other one actually contains more useful info. Marking as duplicate now.
*** This bug has been marked as a duplicate of bug 10421 ***