[yast-devel] YaST module for journalctl

newer
[yast-devel] Pending Pull Requests

older
[yast-devel] Pending Pull Requests

Ancor Gonzalez Sosa

19 Nov 2014 19 Nov '14

09:02

The view_anymsg client is not that useful anymore now that systemd has replaced the good old plain text logs with journalctl. An easy fix to avoid the view_anymsg failure would be to make sure that view_anymsg ensures the installation of any package providing syslog. But that's just a workaround. I miss a journalctl module for YaST (and I would use it, journalctl usage is a pain in the **s). So my plan is to write a new module for journalctl from scratch documenting the process (looks easy but complete enough to be a tutorial). Anybody against it? Any advise? Cheers. -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

Show replies by thread

Josef Reidinger

19 Nov 19 Nov

09:08

On Wed, 19 Nov 2014 10:02:36 +0100 Ancor Gonzalez Sosa wrote:

...

The view_anymsg client is not that useful anymore now that systemd has replaced the good old plain text logs with journalctl. An easy fix to avoid the view_anymsg failure would be to make sure that view_anymsg ensures the installation of any package providing syslog. But that's just a workaround. I miss a journalctl module for YaST (and I would use it, journalctl usage is a pain in the **s).

So my plan is to write a new module for journalctl from scratch documenting the process (looks easy but complete enough to be a tutorial). Anybody against it? Any advise?

Cheers.

I think it is good idea. Just try to make small steps and let someone review it often. Maybe it make sense to integrate it with view_anymsg module as module allows to see also other logs that are not part of journalctl. Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

Lukas Ocilka

09:23

On 19.11.2014 10:08, Josef Reidinger wrote:

...

I think it is good idea. Just try to make small steps and let someone review it often. Maybe it make sense to integrate it with view_anymsg module as module allows to see also other logs that are not part of journalctl.

That sounds like a good idea. - let it reviewed often or maybe present your ideas to someone first, it depends - integration with an existent module for more reasons: people will try to look for it there anyway, and when they are told it's there, they will find even more functionality (advert, first hit for free ;)) Just one little thing against the whole idea - usually, when we develop something new, we should drop something old Additional idea - cooperate with UI/UX expert(s), I'll have a chat with Ken soon to find out how we could find some possibility of cooperation Thanks Lukas -- Lukas Ocilka, Systems Management (Yast) Team Leader Cloud & Systems Management Department, SUSE Linux -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

Ladislav Slezak

11:52

Dne 19.11.2014 v 10:02 Ancor Gonzalez Sosa napsal(a):

...

So my plan is to write a new module for journalctl from scratch documenting the process (looks easy but complete enough to be a tutorial). Anybody against it? Any advise?

That's a good idea! It would be nice to have detailed *step by step* tutorial for the very beginners, IIRC we do not have something like that for Yast. Ideally similar to "Getting Started with Rails" guide [1]. Just a note to view_anymsg: it can display any log file and can be customized via *.desktop file so you can easily add a new file to display, see [2]. Maybe the module could be a generic command runner (or at least provide some reusable library), if it would make sense in this case... [1] http://guides.rubyonrails.org/getting_started.html [2] https://github.com/yast/yast-yast2/blob/master/library/system/src/desktop/me... -- Ladislav Slezák Appliance department / YaST Developer Lihovarská 1060/12 190 00 Prague 9 / Czech Republic tel: +420 284 028 960 lslezak@suse.com SUSE -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

Ancor Gonzalez Sosa

14:06

On 11/19/2014 10:23 AM, Lukas Ocilka wrote:

...

- cooperate with UI/UX expert(s), I'll have a chat with Ken soon to find out how we could find some possibility of cooperation

Yes. I have started with some UI mockups. I though that doing them in libyui would be almost as fast as simply drawing them. I obviously overestimated my skills after 10 years without programming any GUI application. :-) After some hours, I finally have something that resembles what I have in mind (enough to get the idea, I hope) http://paste.opensuse.org/35073071 http://paste.opensuse.org/15368649 Feedback is appreciated. -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

Josef Reidinger

14:15

On Wed, 19 Nov 2014 15:06:16 +0100 Ancor Gonzalez Sosa wrote:

...

On 11/19/2014 10:23 AM, Lukas Ocilka wrote:

...
- cooperate with UI/UX expert(s), I'll have a chat with Ken soon to find out how we could find some possibility of cooperation

Yes. I have started with some UI mockups. I though that doing them in libyui would be almost as fast as simply drawing them. I obviously overestimated my skills after 10 years without programming any GUI application. :-)

After some hours, I finally have something that resembles what I have in mind (enough to get the idea, I hope)

http://paste.opensuse.org/35073071 http://paste.opensuse.org/15368649

Feedback is appreciated.

ncurses screenshot missing time range, which for me looks containing too much stuff. In general it looks too crowded and there is too much control on page and not so much space for messages. I think it will be better to have here only two buttons: refresh ( load new log entries ) filter ( specify filter by time and source ) ( notice that there is no "OK" button, as I think that X for close is enough ) and having almost all space for table with log entries, because it is the most important information. more like this tools: http://www.cisco.com/c/dam/en/us/td/i/000001-100000/75001-80000/75001-76000/... http://www.kiwisyslog.com/kiwiSysLog/media/images/products/LogViewer/carousel/Log-Viewer-Log-File.jpg?width=800&height=560&ext=.jpg http://www.netupd8.com/w8img/972p7d.jpg BTW coloring log entries according to its importance would be nice. Just my 2c. Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

Ancor Gonzalez Sosa

15:02

On 11/19/2014 03:15 PM, Josef Reidinger wrote:

...

On Wed, 19 Nov 2014 15:06:16 +0100 Ancor Gonzalez Sosa wrote:

...
On 11/19/2014 10:23 AM, Lukas Ocilka wrote:

...
- cooperate with UI/UX expert(s), I'll have a chat with Ken soon to find out how we could find some possibility of cooperation

Yes. I have started with some UI mockups. I though that doing them in libyui would be almost as fast as simply drawing them. I obviously overestimated my skills after 10 years without programming any GUI application. :-)

After some hours, I finally have something that resembles what I have in mind (enough to get the idea, I hope)

http://paste.opensuse.org/35073071 http://paste.opensuse.org/15368649

Feedback is appreciated.

ncurses screenshot missing time range, which for me looks containing too much stuff.

DateField and TimeField are not available in ncurses mode.

...

In general it looks too crowded and there is too much control on page and not so much space for messages. I think it will be better to have here only two buttons: refresh ( load new log entries ) filter ( specify filter by time and source )

I agree is too cluttered. Moving the filters to a dialog looks like a good idea, but always combined with a sentence explaining the current active filter. Something like: " Displaying log entries for all sources since system boot [Change...] " Sentences with "moving parts" are usually tricky for i18n, but more intuitive.

...

( notice that there is no "OK" button, as I think that X for close is enough )

Yes, that was a leftover from copypaste. :-)

...

and having almost all space for table with log entries, because it is the most important information.

About that, there is something else I'm struggling with. For each log entry we could also have a detailed version[1]. I'm not sure whether display it in a dialog (when double-clicking in the table row) or whether reserve some space in the interface below the table to display details about the selected row (like we do in sw_single with the packages). I prefer the first because it saves space for the list.

...

more like this tools: http://www.cisco.com/c/dam/en/us/td/i/000001-100000/75001-80000/75001-76000/... http://www.kiwisyslog.com/kiwiSysLog/media/images/products/LogViewer/carousel/Log-Viewer-Log-File.jpg?width=800&height=560&ext=.jpg http://www.netupd8.com/w8img/972p7d.jpg

BTW coloring log entries according to its importance would be nice.

Maybe, but you don't want me to choose the colors :-) Cheers. [1] To see what I mean, run "journalctl -n1 -o json-pretty" -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

Christian Boltz

20 Nov 20 Nov

13:24

Hello, Am Mittwoch, 19. November 2014 schrieb Ancor Gonzalez Sosa:

...

On 11/19/2014 03:15 PM, Josef Reidinger wrote:

...

I agree is too cluttered. Moving the filters to a dialog looks like a good idea, but always combined with a sentence explaining the current active filter. Something like:

" Displaying log entries for all sources since system boot [Change...] "

Maybe you can even make that sentence the user interface ;-) Display log entries [ for all sources v] [ since system boot v] so just include two dropdowns - the first one would have - for all sources - from file ... (open a file dialog when someone selects it) - bar.service - foo.service - ... (one item for each unit) The second dropdown would contain - since system boot - from previous boot - a specific time range (selecting that opens a dialog to enter the time range, and that range should then be displayed in the dropdown) If you discuss this with an UI or UX expert, I'd be interested in his opinions ;-)

...

...
and having almost all space for table with log entries, because it is the most important information.

About that, there is something else I'm struggling with. For each log entry we could also have a detailed version[1]. I'm not sure whether display it in a dialog (when double-clicking in the table row) or whether reserve some space in the interface below the table to display details about the selected row (like we do in sw_single with the packages). I prefer the first because it saves space for the list.

There's always a conflict between a) "wasting" space that could be better used somewhere else and b) forcing people to click a lot (click to open the details, another click to close the detail view) Personally, I prefer scrolling over clicking ;-) so I vote for having a details area at the bottom of the window. Maybe the best solution is to make the split between each area movable, so that people who aren't interested in all details can make the details area very small. Bonus points if the last size is remembered for the next run ;-) Oh, and for the main area - instead of displaying only the raw log message, maybe you could already split it into columns and always display the most interesting columns. Maybe something like Date and time | SYSLOG_FACILITY | SYSTEMD_UNIT | SYSLOG_IDENTIFIER | SYSLOG_PID | MESSAGE Bonus points if this list - allows the user to add or remove columns - remembers the selected columns and their width - the column with date and time cuts away the date (and still displays the time) if it isn't wide enough) If you implement the columns in that flexible way, needing a click for the "all details" view would be acceptable (or even superfluous ;-)

...

...
BTW coloring log entries according to its importance would be nice.

Maybe, but you don't want me to choose the colors :-)

Oh, that's simple - black for notices, red for warnings and red, bold and blinking for errors ;-)) Regards, Christian Boltz --

...

Die M$-Kombination aus Server2003+Exchange ist meiner Meinung nach das einzig vernünftige Produkt von Billyboy. Das muss der Grund sein, warum es bei Würmern und Trojanern so beliebt ist. ["office" und Jens Benecke in suse-linux]

-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

Johannes Meixner

15:06

Hello, On Nov 20 14:24 Christian Boltz wrote (excerpt):

...

Maybe you can even make that sentence the user interface ;-)

Display log entries [ for all sources v] [ since system boot v]

so just include two dropdowns ... If you discuss this with an UI or UX expert, I'd be interested in his opinions ;-)

FWIW: In the initial phase of my YaST Printer redesign I also played with the idea of "inline buttons" directly in meaningful text as in https://en.opensuse.org/File:Printer_jsmeix_overview_all.png I think you can imagine what an UI or UX expert told me... Of course with that fat button design it looks horrible but what I actually had in mind were links in HTML - i.e. "clickable text" but I guess that idea was much too disruptive at that time ;-) Nowadays it is the other way round: In nowadays fancy web pages one can no longer immediately see what is clickable so that one can play pot hitting - have fun! Kind Regards Johannes Meixner -- SUSE LINUX GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 21284 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

Christian Boltz

18:00

Hello, Am Donnerstag, 20. November 2014 schrieb Johannes Meixner:

...

In the initial phase of my YaST Printer redesign I also played with the idea of "inline buttons" directly in meaningful text as in https://en.opensuse.org/File:Printer_jsmeix_overview_all.png

I think you can imagine what an UI or UX expert told me...

;-)

...

Of course with that fat button design it looks horrible but what I actually had in mind were links in HTML - i.e. "clickable text" but I guess that idea was much too disruptive at that time ;-)

I think the bigger problem is that you had 5 lines with buttons - that and having the buttons at different places in each line is what makes your draft a shock therapy for UX experts ;-) Especially the first two lines clearly don't need the text around the buttons - just [Add] [Modify] [Delete] [Print testpage] would be more than enough.

...

Nowadays it is the other way round: In nowadays fancy web pages one can no longer immediately see what is clickable so that one can play pot hitting - have fun!

Yes, some pages are really funny. Let's hope the trend for 2015 is not "black text on black background", because black pages look so beautiful ;-)) Regards, Christian Boltz --

...

It is a pity that [Tumbleweed] fails to continue quickly after an openSUSE upgrade [...] A "pity"? That's a good one, you now owe me a beer for complaining :) [Erwin Van de Velde and Greg KH in opensuse-factory]

-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

Johannes Meixner

21 Nov 21 Nov

10:28

Hello, no longer strictly related to "YaST module for journalctl" but an example how UI/UX development can fail: On Nov 20 19:00 Christian Boltz wrote (excerpt):

...

Am Donnerstag, 20. November 2014 schrieb Johannes Meixner:

...
In the initial phase of my YaST Printer redesign I also played with the idea of "inline buttons" directly in meaningful text as in https://en.opensuse.org/File:Printer_jsmeix_overview_all.png

I think you can imagine what an UI or UX expert told me...

;-)

...
Of course with that fat button design it looks horrible but what I actually had in mind were links in HTML - i.e. "clickable text" but I guess that idea was much too disruptive at that time ;-)

I think the bigger problem is that you had 5 lines with buttons - that and having the buttons at different places in each line is what makes your draft a shock therapy for UX experts ;-)

It does not matter how a very first proposal looks. But it does matter what the intention behind a proposal is.

...

From my point of view the biggest problem was that the idea behind my initial proposal was ignored so that it was "simply rejected" and the 'good old design' of plain buttons without meaningful text in the dialogs was enforced where all meaningful text is banished into help texts regardless that users usually do not read them.

The consequence of not providing meaningful information directly in the dialogs are severe UI/UX issues when users misunderstand a dialog and click wrong buttons leading to wrong results. Examples: In https://en.opensuse.org/File:Printer_jsmeix_overview_all.png I had "Configure [Printing via Network] if a desired remote printer is not shown" but what our users actually got is a simplified until uselessness dialog that results bugs like https://bugzilla.opensuse.org/show_bug.cgi?id=852850 that require a YaST Printer re-redesign https://features.opensuse.org/316789 See in particular https://bugzilla.opensuse.org/show_bug.cgi?id=852850#c7 and compare that with my very first initial proposal idea https://en.opensuse.org/File:Printer_jsmeix_overview.png Guess what: It was a UI/UX "expert" who spent some effort to convince me it is better to mix up local and remote queues and their matching buttons. In https://en.opensuse.org/File:Printer_jsmeix_add.png I had "If no sutiable driver is shown, try [More Drivers] ..." but it was simplified until uselessness that results confused users and various bug reports so that in the end [More Drivers]/[Find More] was re-added (but of couse without any additional meaningful text) https://bugzilla.opensuse.org/show_bug.cgi?id=468046#c17 Guess what: It was again a UI/UX "expert" who convinced me the [More Drivers] is not needed. I do not say that my initial proposals had been already perfect. But I do say that simply removing stuff that smells like an issue instead of a real effort to develop a real solution for the issue results dialogs that may look nicer/cleaner and even work in simple cases but with insufficient usefulness in non-trivial cases. If there had been efforts to develop real solutions for the issues, progress would have happened (of course not an ultimate solution in the first step but step by step into the right direction). I almost never got real constructive contribution from UI/UX "experts". Almost all I got was negative like what not to do, what looks not nice, what to remove, what those "experts" do not like and so on ad nauseam. The only thing what they seem to really like are automatisms that "do the right thing automatically" but when such automatisms exist, there is no need for a user dialog and no need for UI/UX "experts". I would not mind if it was not me who has to fix all the mess that useless UI/UX "experts" introduce. If I had only to fix my own mess and those UI/UX "experts" fix their own mess, everything would be perfect. Kind Regards Johannes Meixner -- SUSE LINUX GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 21284 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

3454

Age (days ago)

3456

Last active (days ago)

List overview

Download

10 comments

6 participants

participants (6)

Ancor Gonzalez Sosa
Christian Boltz
Johannes Meixner
Josef Reidinger
Ladislav Slezak
Lukas Ocilka

[yast-devel] YaST module for journalctl

tags

participants (6)