Welcome
Welcome to refracta

You are currently viewing our boards as a guest, which gives you limited access to view most discussions and access our other features. By joining our free community, you will have access to post topics, communicate privately with other members (PM), respond to polls, upload content, and access many other special features. In addition, registered members also see less advertisements. Registration is fast, simple, and absolutely free, so please, join our community today!

wheezy-based refracta beta2 bugs, discuss, kudos, whatevah

Ask your questions here.

Re: wheezy-based refracta beta2 bugs, discuss, kudos, whatev

Postby meandean » Wed Nov 21, 2012 5:32 am

golinux wrote:None of them tile the baize background of aisleriot solitaire.


Wow that is messed up! I would of never thought that could be a theme issue but I tried it and sure enough you are right.

By the way, the newer Greybird theme tiles it correctly ;)

https://github.com/shimmerproject/Greybird/downloads
User avatar
meandean
 
Posts: 392
Joined: Wed Mar 09, 2011 5:16 am

Re: wheezy-based refracta beta2 bugs, discuss, kudos, whatev

Postby golinux » Wed Nov 21, 2012 5:49 am

When I went to browse my favorite production music sites, they were silent. I checked iceweasel plugins and the ones that used to be in my imported profile were missing. It took quite a while to track down the solution. So if you want refracta users to be able to listen to music online, you'll need to include the gecko-mediaplayer package.
May the FORK be with you!
User avatar
golinux
 
Posts: 663
Joined: Thu Nov 08, 2012 1:23 am

Re: wheezy-based refracta beta2 bugs, discuss, kudos, whatev

Postby golinux » Wed Nov 21, 2012 5:54 am

meandean wrote:
golinux wrote:None of them tile the baize background of aisleriot solitaire.


Wow that is messed up! I would of never thought that could be a theme issue but I tried it and sure enough you are right.

By the way, the newer Greybird theme tiles it correctly ;)

OK. I'll give it a try. If it works, I'll use it as a base to tweak the colors to my liking.
May the FORK be with you!
User avatar
golinux
 
Posts: 663
Joined: Thu Nov 08, 2012 1:23 am

Re: wheezy-based refracta beta2 bugs, discuss, kudos, whatev

Postby fsmithred » Wed Nov 21, 2012 11:02 am

I just tested at the Apple movie trailers site, and got it working, thanks. When you install gecko-mediaplayer, make sure you also get libgpod-common (Recommended) or it won't work.

Yes, please tweak away at these themes. Greybird-master works, but that blue is too much for my eyes. I'd also like to see the icon font changed to sans. I tried it with the stock debian Greybird, and I couldn't figure out what needed to be changed.
User avatar
fsmithred
 
Posts: 2101
Joined: Wed Mar 09, 2011 9:13 pm

Re: wheezy-based refracta beta2 bugs, discuss, kudos, whatev

Postby golinux » Wed Nov 21, 2012 4:00 pm

fsmithred wrote:I just tested at the Apple movie trailers site, and got it working, thanks. When you install gecko-mediaplayer, make sure you also get libgpod-common (Recommended) or it won't work.

libgpod is only needed for Apple stuff, right? Not necessary here. :mrgreen:

fsmithred wrote:Yes, please tweak away at these themes. Greybird-master works, but that blue is too much for my eyes. I'd also like to see the icon font changed to sans. I tried it with the stock debian Greybird, and I couldn't figure out what needed to be changed.

FWIW, I'm going to roll up my sleeves and start by comparing the files in Greybird and master to see if I can pinpoint the tiling glitch and then try to get a better handle on just how the theming works. I'm hoping I might be able to create a gtk3 compatible theme for tropic bomb as greybird still isn't doing it for me.
May the FORK be with you!
User avatar
golinux
 
Posts: 663
Joined: Thu Nov 08, 2012 1:23 am

Re: wheezy-based refracta beta2 bugs, discuss, kudos, whatev

Postby thwak » Wed Nov 21, 2012 7:47 pm

golinux wrote:One of these days, I'm gonna have to spend some time figuring out exactly how GTK 3 themes are set up. I'd never do it with a gui
FWIW, the best GTK3 theming tutorial I've seen is: http://worldofgnome.org/making-gtk3-the ... -1-basics/

see if I can pinpoint the tiling glitch and then try to get a better handle on just how the theming works
don't strain yourself ~~ it's a fux0red scenario we're in, collectively.
The "standards" geniuses have handed us (users, and would-be theme authors) a multivariant environmental mess to deal with:
result FOR A GIVEN USER depends on:
app (widgets) + theme css stylesheet + app engine

...but wait, there's more! Order in the next fifteen minutes and, as a bonus, we'll throw in these additional variable conditions:
app engine VERSION
AND
theme VERSION

When you author a theme, you're authoring against gtk-theme-enginename v12.4-16
Tomorrow, theme engine author(s) will discover, oops, libgtk3 v plusminus3.oops.79-6 chokes our engine
so theme ENGINE author releases incremental gtk-theme-enginename v12.4-17
and you, the theme author, instead of revising your theme description (however many places it's published, online) to include a disclaimer that it "not worky with gtk-theme-enginename >12.4-16" ...you fuel the confusion by re-releasing an incrementally changed, numbered, version of your existing "named" theme.

Reiterating my earlier point: don't strain yourself. Any theming quirk you fix today, someone may break again tomorrow.

I would love to have a simple way to tweak the colors in a theme

I've wasted a lot of time searching -- no such monkey.
skim the following page and note bwackNinja's comments:
http://igurublog.wordpress.com/2012/11/ ... in-threes/
thwak
 
Posts: 174
Joined: Tue Nov 20, 2012 3:58 am

Re: wheezy-based refracta beta2 bugs, discuss, kudos, whatev

Postby golinux » Wed Nov 21, 2012 8:10 pm

Thanks for the info. You have obviously looked into this more than I. I surrender! And will make do with the setup I already have. I'm hoping that by the time wheezy is stable, there will be better options.

The whole gnome thing is a huge mess. It's almost as if they're trying to alienate users by making cross-compatibility nearly impossible. I am so over gnome desktop. In time, hopefully gnome apps will also find replacements in a more community-friendly format.
May the FORK be with you!
User avatar
golinux
 
Posts: 663
Joined: Thu Nov 08, 2012 1:23 am

Re: wheezy-based refracta beta2 bugs, discuss, kudos, whatev

Postby thwak » Wed Nov 21, 2012 9:41 pm

gnome... mess
I do worry. I worry about the possibility that the current mess "is not accidental".
This ridiculous trend toward complexity (and obfuscation) in regard to performing simple (bgcolor) changes to UI prefs
..along with dumbing-down the userbase in general, sure feels an agenda intended to overwhelm / intimidate users, driving us away from desktop use and onto spoonfed, lock-in, "computing appliances" and / or "cloud" services.

(this is a "whatevah" thread so, yeah, I'm rambling)

Last night, with the hope of replacing "tomboy" (many, chained, gnome dependencies) with its feature-compatible analogue "gnote", I realized that debian repos only contain gnote v0.7 (its current version is v3.7!), so I downloaded its sourcecode, built, and found that once built (without error) it still fails to launch! In this particular case, I can't blame the author, I can't blame the "package maintainer"... so where to point the finger of blame? What seemingly inexplicable "magic" prevents the app from running under debian? It's continually "like that" at every turn, dammit -- "accept what we (bless and) provide from the repos... or expect to fail!"
thwak
 
Posts: 174
Joined: Tue Nov 20, 2012 3:58 am

Postby thwak » Wed Nov 21, 2012 11:59 pm

Bleachbit looks way cool, and I'll probably add it. (Haven't tried localpurge yet.)

localepurge provides "forward looking" attention to cleanup.
Its post-install trigger handles many (not all!) lang files placed by newly-installed packages.
-
bleachbit's cleanup of localization files is just one tiny prong of its functionality.
It auto-recognizes many installed apps + gives user granular options to clean (or not) junkfiles for each app
AND, perhaps more importantly, provides a GUI where user can enumerate custom cleanup paths/files
(Hold that thought...)

gnome-icon-theme - every time I run graphical disk map, I see that huge block,
and I want to get rid of it, but brasero, gdebi and evince depend on it.
Nixing icons PER APPLICATION, for any/all which aren't present in the distro should not cause a dependency problem.
Usage problem? Upon later installation, if user winds up with "broken" icon... can re-install the "gnome" iconset package, eh.
-
Additionally, consider: will you (or a user of your distro) _EVER_ need to see a 128x128px version of "icon for appXYZ"?
Personally, I nix ALL "sized" app icons larger than 32x32
(at the same time as weeding out icons for myriad gnomy apps I know I'll NEVER install)
Even if you retain the sized versions up to 48x48px, removing the imagefiles for the stoopidly-large versions of the icons eliminates MOST of the overhead.

^--- The chore of weeding out the icons isn't necessarily on your shoulders.
Mentioning it (the prospect of weeding out iconfiles) within a "optimization tips" document should suffice.

redundant menu items - I'm aware of a few, but not in the setting menu.
I see synaptic, gparted, time and date, and midnight commander in Accessories and System.
I don't notice it, because every linux I've used since 2000 has had redundant listings in the menu. Is it really a problem?
Problem?
Well, it's "par for the course" in terms of the loving care (or lack thereof) invested in creating a "distro".
We "see it for synaptic, gparted" because upstream numbnutz declare multiple categories in the Categories= line within the app's .desktop file
(okay, not numbnutz, more accurately "one-shoe-fits-all" nuts)
Fix this for the apps distributed within your "distro"... or don't, it's your call.


More thoughts about purging personal data before making a snapshot -

Right now, the excludes file eliminates a lot of sensitive or potentially sensitive data.
The user needs to manually edit that file if they want to include or exclude anything different.
Should there be a graphical excludes editor in the snapshot tool? Separate excludes files for different purposes?
(snapshot_exlcude.list.I_want_to_put_all_my_sensitive_data_on_the_live_system vs. snapshot_exclude.list.I_want_to_give_this_one_away)

I think I prefer empowering the user to make their own choices about what to exclude.
Maybe I just need to put more comments in the existing excludes file.
Adding some instructions for using bleachbit is a good idea, too, but I don't see it as a replacement for the extensive excludes file.
(Example: I don't want to share my ~/.ssh folder, but I also don't want it bleached from my hard drive.) Will have to play with bleachbit and see what it does.


I'm grateful for your effort in creating/maintaining refractasnapshot, but I'm not likely to install and use your "distro". Compared to SalineOS for instance, frankly I can't see much, if any, "added value" in the separate refracta distro, nor can I understand the motivation(s) involved in pursuing separate, redundant, projects. If refracta and salineOS and antix were all on the same page (under the same "brand") including a central, shared, user forum... I believe we all (devs + users) would benefit.

The "hold that thought" above == custom paths.
"make their own choices about what to exclude" (and / or include)
GUI or not, are you really eager for refractasnapshot to accommodate various use cases?
When user executes refractasnapshot, is his goal:
A) create a "distro" ( "redistributable" ~= exclusive of any personal info, inclusive of .configs ) ?
B) create a snapshot-in-time, for backup or migration purposes
C) something else

Compared to debian net-install, the value added by a given niche distro (to be used as a base) entails:
-- bundled /skel and /opt "enhancements"
-- "best practices" attention to pre-populating config details with SANE defaults
-- ease of preserving, and later migrating, "all my stuff(s), tweaked just da way i likes"

If a "distro" is gonna embrace xfce, the distro dev should EMBRACE xfce, to the extent of collecting, and including, various creative "custom thunar actions"... and documenting their inclusion. (kudos to salineOS for doing so.) The dev of an xfce "distro" should understand (and include) the usefulness of the "xfapplets" panel plug-in...

my point here is this:
Among the current crop of debian-derived and ubuntu-derived "distros" featuring xfce, MOST of 'em represent "somebody's ego trip" rather than serving as a meritworthy showcase for an xfce-powered environment. By focusing on which custom paths refractasnapshot might EXCLUDE, I worry that you are accommodating the least-desirable (IMO) use case, fostering a "whee, lookit me, i made a new distro" mindset.
thwak
 
Posts: 174
Joined: Tue Nov 20, 2012 3:58 am

Re: wheezy-based refracta beta2 bugs, discuss, kudos, whatev

Postby nadir » Thu Nov 22, 2012 4:38 am

For starters they care **** about free or not free at SalineOS (from what i have seen).

Else? No comment. You already made up your mind, without knowing the history of the "project" at all (which starts with calling it a distro and by calling it an xfce4 distro. It uses xfce, per co-incidence. It could use any other environment/window-manager too. That's not the point).

If anyone wants or needs some loving from me (aka the long history of the project) i am able to give a detailed rant. In short: go on . Good job and good purpose.
So i herd u liek mudkip?
User avatar
nadir
 
Posts: 1160
Joined: Wed Mar 09, 2011 4:18 am
Location: here

PreviousNext

Return to Help

Who is online

Users browsing this forum: No registered users and 0 guests

suspicion-preferred