Isn't it time to build a graphical package manager Chapter 2

This is intended as a follow up to this old thread. In this thread: http://forums.freebsd.org/viewtopic.php?f=5&t=29154.

I was complaining - as an old FreeBSD user (if memory serves me well, I started to look at FreeBSD starting from version 4) - about, in all these years, nothing serious was done related to package management. And yes, I do confirm, the pkg_ suite of programs was horrible and binary support - needed by every modern OS, not depending on the platform - was pretty much not existing, at the time of that writing, but...

I'm happy to admit that (seriously, they listened to my and many others complains) - starting from FreeBSD-10.0 - binary package support is now excellent, with the new pkgng suite of programs and constant, updated binary servers, up to date in hours after a new port is released. This is the way to go, for sure. And a big compliment to the foundation that realized this was mandatory.

Then, something is still missing, and it is a graphical front end for the pkgng suite of programs. I hope to see something serious, related with it, soon. BTW, IMHO, a graphical interface is mandatory, because in 2014 the command line makes no sense but for a bunch of (useless?) geeks.
 
Re: Isn't time to build a graphical package manager CHAPTER

Then, something is still missing, and it is a graphical front end for the pkgng suite of programs. Hope to see something serious, related with it, soon. BTW, IMHO, graphical interface is mandatory, becouse in 2014 the command line makes no sense but for a bunch of (useless?) geeks.

Your 15 minutes of fame were already many years ago and we already know what you have to say, we are not falling for your trolling anymore.
 
Re: Isn't it time to build a graphical package manager Chapt

fonz said:
piggy said:
Then, something is still missing, and it is a graphical front end for the pkgng suite of programs.
Install x11/xdialog and go ape. It's not that difficult.
Hemmm I do write this from my iPad and I just read the program related web page. How can you call that a graphical native user interface to pkgng?
 
Re: Isn't it time to build a graphical package manager Chapt

piggy said:
How can you call that a graphical native user interface to pkgng?
You didn't use the word "native" until you snuck it in there just now. If by that you mean a GUI should be built into pkg itself, that's not going to happen, for obvious reasons. However, it is of course perfectly possible to create a port that provides a nice GUI (and/or TUI) frontend for pkg. I pointed you to Xdialog because I think that's probably the easiest way to do it. All it takes is a bit of shell scripting, so feel free to dig in. To get you started, here's an example of how I recommend you actually invoke Xdialog:
Code:
#!/bin/sh

DIALOG=/usr/local/bin/Xdialog
DIALOG_GEOMETRY=640x480
DIALOG_OPTS="--fill --no-tags --stdout"
DIALOG_TITLE="My pkg frontend"
DIALOG_MACRO='${DIALOG} ${DIALOG_OPTS} --title "${DIALOG_TITLE}"'

DIALOG_OK=0
DIALOG_CANCEL=1
DIALOG_HELP=2
DIALOG_PREVIOUS=3
DIALOG_ERROR=255

RESULT=`eval "${DIALOG_MACRO} --backtitle 'Main menu' \
  --cancel-label 'Run away!' --default-item FOO \
  --menu 'Welcome to pkg, bla bla bla.' \
    ${DIALOG_GEOMETRY} 0 \
    FOO   'Option 1' \
    BAR   'Option 2' \
    FEEP  'Option 3'"`

case $? in
  ${DIALOG_CANCEL})
    exit 0
    ;;
  ${DIALOG_ERROR})
    echo "Holy crap on a cracker!"
    exit 2
    ;;
  ${DIALOG_OK})
    case "${RESULT}" in
      FOO)
        # do something similar to spawn sub menu 1
        ;;
      BAR)
        # do something similar to spawn sub menu 2
        ;;
      FEEP)
        # do something similar to spawn sub menu 3
        ;;
      *)
        echo "Yikes! ${RESULT}"
        exit 2
        ;;
    esac
    ;;
  *)
    echo "Holy crap on a cracker!"
    exit 2
    ;;
esac
Good luck. And feel free to ask if you get stuck and/or if you need help submitting your work to the ports tree when it's finished.

P.S. You may want to organise the script into functions or split it into several sub scripts, in order to streamline it and make it more maintainable.

P.P.S. It's possible to add an XPM icon (such as the FreeBSD logo) to the dialogs, to make them look just that little bit spiffier.

P.P.P.S. Xdialog supports help buttons. You'll probably want to tie these into pkg help <something>.
 
Re: Isn't it time to build a graphical package manager Chapt

Come on, Fonz, be serious, thank you for the effort to show me some boring and out of time script (for end users) that is completely out of the scope of my message.

I ask for a UI just because I think even typing some commands on the prompt is totally out of fashion these days, even for FreeBSD, if we talk like end users. Commands are for developers, and not even any more these days with graphical programming interfaces and languages.

I know, there is PC-BSD having something like that, so it could be implemented in FreeBSD pkgng too, I'm sure it could be definitely appreciated by the user base.

PS: PC-BSD is out of the question for me starting from when they made version 9 without offering the option to upgrade from version 8. So dumb in the rolling releases years :(

PPS: The right UI for pkgng should be something like GNOME software you surely know (from GNOME 3.1x), maybe something compliant to GTK or even something like Aptitude, to stay in the boring command line world. I just think something should be done, and without waiting four years more.
 
Re: Isn't it time to build a graphical package manager Chapt

piggy said:
Come on, Fonz, be serious
I was, actually. You're the one who wants a graphical front-end for pkg, so I showed you how you could make one.

piggy said:
I think even typing some commands on the prompt is totally out of fashion these days, even for FreeBSD, if we talk like end users. Commands are for developers, and not even more these days with graphical programming interfaces and languages.
That may be your opinion. Most people here seem to disagree with it. There are probably reasons for that...

piggy said:
I just think something should be done
Feel free to start doing something, then.
 
Re: Isn't it time to build a graphical package manager Chapt

Doesn't the bsdconfig port include a TUI for installing packages? And the PC-BSD folks have a Python-based GUI for installing packages (not PBIs, that's a separate GUI). And wasn't there a GSoC project last year around this topic? I'm not sure what came of that.

And, for the love of all that's holy, please do not suggest GTK+ as a GUI framework for anything.
 
Re: Isn't it time to build a graphical package manager Chapt

phoenix said:
Doesn't the bsdconfig port include a TUI for installing packages?
There are several applications in the ports-mgmt section of the ports tree already. Some are TUIs, others are GUIs. But I don't know whether any of them support the new pkg system yet. I didn't bother to check, because /bin/tcsh works good enough for me ;)
phoenix said:
And, for the love of all that's holy, please do not suggest GTK+ as a GUI framework for anything.
Just out of curiosity: what would you prefer, then?
 
Re: Isn't it time to build a graphical package manager Chapt

I'm pretty sure bsdconfig, from Devin Teske and company, has been updated to use pkg. I'm not 100% sure, as I don't use GUIs for package installation (not even on Linux) but I do recall something along those lines in a thread on the -ports mailing list.

[edit]Hrm, but upon further consideration, it looks like bsdconfig doesn't actually install packages. I must be thinking of something else then. I'm sure it was Devin who was working on a TUI for package installation as part of bsdinstall, but now I'm not sure sure. :( [/edit]

[edit2]Aha! I thought so. Devin sent a message to the -current mailing list in November of 2013 with patches to integrate pkgng into bsdconfig. I don't know if this was integrated into the port yet or not. Again, I don't use TUI/GUIs for package installation.[/edit2]

I don't have a preference for which GUI toolkit should be used, with the sole exception that GTK+ should not be considered. I have yet to hear/read a single good thing about the GTK+ developers, the direction it's going, their policies around accepting patches, their willingness to support multiple platforms other than Linux, their willingness to support older versions, or even their ability to document things.
 
Back
Top