BBQ Roaster Dev

[DebianJoe]

No defaults.

I will do my best, then, to explain in the config how to set them up if you should so desire to use hotkeys, and lay out a frame-work that ignores nulled values if you do not wish to apply them.

[machinebacon]

Excellent. The guys who use no mouse are usually capable of checking config files, so I'm confident. Great idea, indeed.

[DebianJoe]

Okay, working version with fully-configurable keyboard shortcuts up on git. I'm going to add some notes to the README (keeping in mind the BBQ philosophy) and it should be ready to roll. I still hate gtk.

BTW: Stop by and "star" this project. It's currently less favored than a crappy Roguelike that's in my repos. This is unacceptable.

edit: Also, in an effort to avoid bloat, due to the fact that this last change increased the lines of code by about 50, I cleaned up some of the junk in there to make it almost the same size as it was previously. Just say "NO" to bloat. ;)

Bookmarks next?

[DebianJoe]

ALSO...since I guess nobody had attempted it (because I'm sure someone would have mentioned it), I fixed the wget_it option for when it wasn't over a link, so as to save the current object in the main frame regardless of data-type.

So, freedom to download everything now fully functional.

I've got the ability to pull current_page and linked-page urls into the links2 bookmarks file. Look for that to be added by the end of the week. ;)

[dkeg]

Awesome DJ. Haven't hopped back on the roaster train since d-day. I'll give it a clone and I'll be sure to give some git love too.

[DebianJoe]

The hotfix to wget helps to get pics of women in lingerie (the stated purpose of starting to work on it). If you followed a link out to a simple file, wget_it failed. I managed to drop a fix in for this, so now you can either get the target of a line (if that's what you've moused over) or the page/file itself (if not over a link).


^^Example

I figured that everyone was too busy rolling out distros, making busybox work, adding wiki entries, and whatever else we were doing to notice this, and I'm happy to have fixed it before someone ran into the issue and started yelling at me about it.

Thanks for the props, dkeg.

[machinebacon]

Ha, I did notice it before but thought it's not yet implemented, so I didn't bother to nerve you.

Yes, I'd love bookmarks. Can you/we make them share ~/.links2/bookmarks.html or whatever the name of links2's bookmarks was? Does

Code: Select all

os.system ('echo' + str(url) + ' >> ~/.links2/bookmarks.html')

work? :D Naive me.

[DebianJoe]

Python can write into a file without a system call, so it's not necessary (aka: It is bloat!) to do it that way...and:

The file will need to be written to before the last line. ">>" just appends, correct? If you look at the html file that is links2 bookmarks, it is pre-formatted.
When using "Bookmark Current" the tag won't be url so much as WebView.main_frame().get_uri(), which could be named with get_title() at the end of it to make it call the file something nice rather than the entire http://whatever.com/wer/a/foo/bar/spam/eggs, etc file. I'll play with it to get it to work. This WILL be easier than the last big change.

[machinebacon]

Thanks Joe.

True, I haven't actually checked the bookmarks.html file, but of course it needs to have a formatting as it's an html file... stoop me (keep in mind that it was already midnight when I typed this :D ).
And as for the >> to append, yup, this was meant like this. First bookmarks first, though I really don't care in which order they go - alphanumeric would be a bliss, sort by date is good, too. And even better if they would autocomplete in the address field. Dreaming too much?

[DebianJoe]

What I mean by "pre-formatted" is that not only are there string inserts for basic HTML formatting, but the location of everything within the file needs to be maintained:


To keep things as small and simple as possible, it would be the most direct method to simply allow them to be placed in the order that they are created.

With some minor string manipulation, I can get them ordered...but links2 gives the option to reorder items, and it would be a issue to keep the two from fighting with one another. It would only be an issue on switching between the two, though.

As far as auto-complete in the text-entry field, I (think) that it can be done by performing a scan of the HTML file, removing all of the html-tagging, and then offering completion data by doing a char-array check from what has been entered vs. what's in the file. There might be a better way to do it, but I've not thought of one yet. This could be a heavier process to be using an interpreted language for, as it would be checking every position in the character array for each item in the list in as close to real-time as I could get. I may have a moment of brilliance and come up with a better way to do it, but as it stands...I don't think that the added functionality would be worth the extra drag on resources.

I may set up a simple system for now, and hope that the muse of artistic coding visits during the process. The last suggestion would certainly be the most interesting from a problem-solving standpoint. What I'm afraid of is giving up what it does well by adding so much extra as to make it little more than a poorly implemented Chromium. I'll do what I can up until I feel like we're simply trying to recreate a full-featured browser in a less-than-efficient language.

[DebianJoe]

One of the thing that I'd really like to accomplish is to break ground with what we can offer. I like the idea of cross-integration. I like what we've done with the UI so far. I like the fact that really, in the end, roaster is simply a very neat script. It's just one file, and keeping that file within the scope of light-weight usefulness is a limiting factor. If we were going to try to automate everything for the user we'd need to make it an true installation, and then there are better choices than python as a base.

On the other hand, some people do Sudoku puzzles, some play video games....I try to come up with neat ways to do things with code. In the end, though, I am just one dude sitting around in my sweatpants after hitting up the gym and a shower, and trying to figure out how to meet what I'd like to see out of the project while implementing as much functionality as possible in the 30 minutes to an hour I can work on it every couple of days. Unfortunately, I'm not Google. I don't have a 20-man-team working 40-50 hours a week. You'll get the best I can offer, but that doesn't mean that it will meet every expectation/dream. Still, please throw out fun ideas. I am enjoying this project.

[ivanovnegro]

In the end, though, I am just one dude sitting around in my sweatpants after hitting up the gym and a shower, ...

The reason why it will be the best thing on earth. :D

[pidsley]

I'll do what I can up until I feel like we're simply trying to recreate a full-featured browser in a less-than-efficient language.

I like this plan. Don't let feature creep overcome simplicity. I see this all the time -- "How can I make <simple tool> do everything <readily available complex tool> can do?" Or the feature requests end up turning <elegant simple tool> into just another <bloated slow complex tool>. In my mind, you're building a bicycle, not an SUV. Bicycles are the most efficient transportation system ever invented.

[rhowaldt]

^ that's the second time i catch you waxing poetically pidsley. i marvel at your words, they are Nice (with a capital N). your bicycle-statement means a lot to me as a Dutchman especially.

[bones]

I agree with keeping it simple. I'm liking what I'm seeing with what you have been doing so far, but I'm not looking for a Firefox replacement, I want something that's quick on its feet.

[DebianJoe]

So far, just to keep you guys posted on how I think we can maintain the "bicycle approach" while adding some neat little features:



I have roaster currently reading the links2 bookmark file and rather than displaying it as an extra pop-up gtk menu, or a separate widget, I'm just loading it directly into the WebView uri. This does have hotkey compatibility and an entry for binding those in the config file, so that's already available. It works just like a remote page, so it's easy to use and navigate from without adding any complication. I've got the function calls created for adding bookmarks via links and on current there...but right now they simply print debug messages to the console.

Assuming you want to try it out, it's functional...but links2 will be your bookmark manager until I figure out how to best handle following their formatting for the html file. In the end, adding file management to translate home/$USER to a usable url, extra hotkey bindings and their calls, the menu item, and the definitions for calling the file cost me about an extra 25 lines of code. I think that this direction won't have any significant impact on Roaster's performance, yet does add some "quality of life" features.

Edit: All changes mentioned pushed through git, feel free to test.

[DebianJoe]

Not to drag this out too far, but I've been really contemplating what Pidsley said and have added some "design concepts" to the project with a reference to the LinuxBBQ Philosophy.

From the info I added at Github : "Roaster was created with a few goals in mind, and all changes are expected to abide by the LinuxBBQ Philosophy. As nice as extra features are, they are only implemented if they add to the user's experience without significantly impacting performance. The entire project is purposely designed to be contained in a simple script. There is already one Firefox, so there's not much point in trying to recreate their entire project. We hope to provide something simple, and distinct."

In order to accomplish this goal, I've set a few restrictions to what I'll allow in pull-requests, and demand of myself. Just for fun, I'll add the references to how this ties in with the overall philosophy by providing {section:item} where appropriate:

1. We've already got enough external imports to do tons of stuff, so don't add any more.
a. The user shouldn't have to go searching for 20 Python modules just to make a browser work.{General: 5}
b. Using basic system tools that are readily available leads to a smaller install size.{General: 8}
c. Python comes with multiple libs that can be used without having to search out new items.{General: 5}
d. Using os.system allows some neat tricks that aren't exactly "Pythonic", but are really efficient.{General: 10}
e. Less Imports == Less Bloat.{General: 5&8}
2. Code should be in one file...less than 1000 lines long, and still meet pep8 compliance, or attempt to.
a. This makes programming more fun. Anyone can hack together a function. It takes a samurai to do it in a single slice. {General: 5}
b. Less Lines == Less Bloat.{General 5&6}
c. pep8 is the standard, let's make sure that we're not hacking lines just to save some space.{Design: 6}
d. It's easier to cp /etc/roaster ~/roaster or whatever you want to do with it than to perform a huge migration. {General: 5}
e. If you want to hack it, it's all inclusive.{General: 9}

tl:dr, If we're going to have a philosophy, then we should be able to justify design choices based on it. I'm starting to think about how to best do everything by putting limits on how features should be implemented.

[DebianJoe]

....and now bookmarking in Roaster is working, reflected in links2, links2 still works, and is reflected in Roaster.

If you wish to change the default naming scheme for a link, I'd use links2 or just hack the html for now. I've tested it with both subsection (which is supported by links2) and a base html. Both work, so I pushed the changes.



Feel free to test it. I had an openSUSE Tumbleweed guy run it to test drm flash, and it would appear that works as well if the system is running HAL or a fake-HAL layer.

[rhowaldt]

DJ just made a valid point. it was regarding the Philosophy. you must be really glad i added those numbers in there recently :)
btw, if you run into stuff that you feel should be covered by the Philosophy, let me know. it might be incomplete, as is everything.
thanks for all the hard work! no time to test it now, but i'm sure people will :)

[machinebacon]

Very happy to see the direction 'roaster' goes. For me, personally, it has reached the state I was looking for and I have no further feature requests. Doesn't mean that I don't welcome changes :)

Thanks DebJoe, you're now on our front page ;) http://linuxbbq.org/about.html (scroll doooown)