<qi-bot>
[commit] Ayla: The translations can now be located on the system directory, or on the user-specific directory. http://qi-hw.com/p/gmenu2x/c18c230
<qi-bot>
[commit] Ayla: The "configure skin" will now list all the skins present on the system and the user-specific directories. http://qi-hw.com/p/gmenu2x/f4b0310
<qi-bot>
[commit] Ayla: The wallpapers will now be loaded from the system and the user-specific skin directories. http://qi-hw.com/p/gmenu2x/f2b34f3
<qi-bot>
[commit] Ayla: The user skin directories were not created when saving the skin.conf file; Thus it was never saved. http://qi-hw.com/p/gmenu2x/12a7fe4
<Ayla>
hello there
<wpwrak>
aw_: seems that your prediction was right :)
<aw_>
wpwrak, hup...just saw them.
<aw_>
wpwrak, not surprised though. checking...
<aw_>
wpwrak, atusb they used "stamp" linked together.
<aw_>
wpwrak, 10 pieces in one panel is good idea though. but I wouldn't link 10 pcs in a long row. Two rows in totally for 5 pcs: 2 * 5 pcs for me. but this needs to ask smt vendor to see if they can mount with problem.
<wpwrak>
aw_: hmm yes, particularly when we add the holes, the long row may get a bit too elastic
<aw_>
wpwrak, but since have to separate the individual USB A type connectors mounting by manually soldering by manufacture( which I would not suggest, you will get messy quality then)
<wpwrak>
aw_: i wonder how those usb connectors will turn out
<wpwrak>
aw_: the idea is to make that hole, so they can be SMTed. with a 2 x 5 board, that should still be possible, no ?
<aw_>
wpwrak, a good smt vendor they will have their own fixtures to carry atusb boards to pass through dip reflow machine.
<aw_>
but i don't know if that smt vendor they can/have do that.
<aw_>
wpwrak, yeah..i am thinking..
<wpwrak>
aw_: ah, dip reflow ... first time i hear of that. sounds fancy ;-)
<aw_>
wpwrak, your A USB type connector is not smd parts i think. isn't it?
<wpwrak>
aw_: it's sold as "SMD" ;-)
<aw_>
wpwrak, if no tap can be picked/placed by SMT machine. they should surely being mounted by manually. it will not be mounted by smt machine itself.
<aw_>
it would go through dip reflow machine. so before atusb goes in.they are all seperatedly already. with this way...we are not sure the horizontal level synced with pcb correctly. i hope david know this critical condition.
<wpwrak>
aw_: yeah, i expect manual mounting. the connector also needs to be pushed a bit
<wpwrak>
aw_: (dip reflow) since the SMT fab insists on having a hole for the connector, it seems that they will try to do it all in the SMT process
<aw_>
wpwrak, yup, IF SMT fab insists on all things done on smt machine line. it surely is good.
<wpwrak>
aw_: let's hope for the best ;-)
<aw_>
wpwrak, i saw yours replies, it's good/clear explainations for me. but please let/make david fully understood this though. :-)
<wpwrak>
aw_: e.g., i'm not so sure the "cowboy legs" will get properly soldered. but then, tuxbrain can do this in a few seconds by hand :)
<aw_>
wpwrak, yes, if he can be stayed there (i am not sure how far his smt vendor to him), when first panel goes out smt machine before going into reflow mahchine. check if all parts's placements and balances.
<aw_>
wpwrak, then that 'reflowed' first panel must checked by david or smt machine they can guarantee them. to see if needs extra manually soldering then.
<wpwrak>
aw_: i hope he'll be able to flash and run tests right there
<aw_>
wpwrak, EACH piece with four 'stamps' area, hope they have strengthness enough while mounting.
<wpwrak>
aw_: we'll see ;-)
<wpwrak>
aw_: ah, and it will become just three "stamps" when they make the hole. not sure if adding more "stamps" on the long sides would help much, though
<aw_>
wpwrak, less one 'stamp' with heavy USB connector, I can imagine the process of SMT machine mouting. :-) so adding more 2 holes on rest 3 stamps is good i think.
<aw_>
the heavy parts are normally being mounted later than other smd devices, so your boards won't be stay at good horizontal level.
<aw_>
well.. some SMT machine can still place smd devices very well even pcb stays unbalanced.
<aw_>
wpwrak, do you know that smt vendor how they cut atbens 'stamps' on panel?
<aw_>
wpwrak, hope they won't cut/break your ANT. :-)
<wpwrak>
aw_: (2 more holes) ah yes, making them bigger may also be an option. good idea.
<wpwrak>
aw_: (cut) no idea how they'll cut. let's hope the antenna doesn't get twisted too badly :) (well, you can always bend it back ...)
<mth>
kyak: the "install_locations" branch is something we need for OpenDingux, since we're going to put gmenu2x in the rootfs and our rootfs is read-only
<mth>
so Ayla is modifying gmenu2x to be able to read from both a read-only installation location and a read-write location in the user's home dir
<mth>
if this approach makes sense for the NanoNote as well, then "install_locations" can be merged back into "master"
<kyak>
mth: do you mean that usually it attempts to write to the installation location?
<mth>
afaik, yes
<Ayla>
it reads/writes the files on the binary's directory
<mth>
oh, even worse
<Ayla>
which means that if you put the binary in /usr/bin, you have to put all the files like translations, skins... in /usr/bin :)
<kyak>
what a crap
<Ayla>
so it wasn't possible to package it
<kyak>
oh yeah, in Ben the binary is somewhereis in /usr/share/gmenu2x (with all the other files) and a wrapper script in /usr/bin
<Ayla>
so the user files are saved in /usr/share/gmenu2x?
<kyak>
there are no "users" by default :) root only
<kyak>
if you change/add something, yeah it would be saved in /usr/share/gmenu2x i suppose
<Ayla>
yes, like on dingux, but the app shouldn't rely on that
<kyak>
of course
<Ayla>
anyway, I finished the job on the install_locations branch, it's ready for testing
<Ayla>
it works like a charm on OpenDingux
<Ayla>
here the binary should be directly on /usr/bin (no symlink needed), and a minimum number of files in /usr/share/gmenu2x: the input.conf, the "skins" directory with the Default skin, and the "translations" directory
<Ayla>
and everything the user modifies will be saved on its $HOME
<kyak>
mth: i remember you wanted to drop the SDL_image dependency and only have libpng support in gmenu2x. Did it work out fine? How much memory were you able to save?
<kyak>
Ayla: what about the icons?
<Ayla>
what about them?
<kyak>
to you supply some default icons?
<kyak>
how to change/edit them? since they are read-only
<Ayla>
only those inside the Default skin
<Ayla>
(the icons for the "GMenu2X" config, the "Skin", the "Wallpaper" entries...)
<kyak>
yeah
<kyak>
so what if a user want to edit the icon or remove it?
<Ayla>
well, all the icons are first searched inside the user $HOME directory
<Ayla>
for instance, if you want to modify /usr/share/gmenu2x/skins/Default/imgs/cpu.png you just have to copy the modified icon to ~/.gmenu2x/skins/Default/imgs/cpu.png
<mth>
kyak: it does work, but I want to clean up the code a bit more before I commit it
<kyak>
Ayla: ah, that's all right! What i really mean is "sections"
<kyak>
Ayla: like, sections/applications/.. .
<Ayla>
well, the sections are also saved on the $HOME
<Ayla>
some are created by default (the classic "applications", "emulators", "games" and "settings" sections)
<kyak>
so basically, when i try to edit some icon (i.e. section) via gmenu2x, it would save the result to my $HOME?
<Ayla>
AFAIK you can't edit a section's icon, that's a missing feature
<kyak>
hm.. i remember it's Alt+F2 or just F2
<kyak>
then you have a popup menu when you can edit the icon
<Ayla>
ah, I can't do that on dingoo
<kyak>
(basically it's the same as editing the file manually)
<Ayla>
by "edit the icon" you mean selecting a new file?
<kyak>
not only that
<kyak>
it allows selecting another binary, or specifiying parameters, working dir etc
<kyak>
brightness
<Ayla>
ah yes, but that's for a binary, not for a sections
<Ayla>
section*
<kyak>
everything that's inside the usual icon (section) file
<Ayla>
yes, all of that work fine
<kyak>
nice :)
<qi-bot>
[commit] Werner Almesberger: tools/atrf-proxy/PROTOCOL: added specification of asynchronous WAIT command http://qi-hw.com/p/ben-wpan/6e0657e
<qi-bot>
[commit] Werner Almesberger: tools/lib/atnet.c: eliminated global variables to allow for multiple sessions http://qi-hw.com/p/ben-wpan/8f7e5cd
<rozzin>
the "git checkout --track -b local_backfire origin/tracking_backfire" bit isn't working for me.
<rozzin>
I gather this is because the only thing under .git/refs/remotes/origin is HEAD.
<cfy>
hi all, does qi-hardware plan to produce a mobile phone?
<rozzin>
cfy: *right now*?
<cfy>
rozzin: not now,it seems that my mobile phone is not good now.so i plan to buy a new one:)
<rozzin>
sighs. Hates git.
<cfy>
hehe
<rozzin>
It just always seems to insist that the most important thing I have to do is read through the implementation of the VC system trying to figure out how to disambiguate things.
<rozzin>
Like, how to just tell it explicitly to do what I want it to do instead of having it guess at what Linus would want in whatever the closest approximation of my situation would be in Linux.
<wpwrak>
Jay7: you got that wrong. if she relented already twice, you should make use of that weakness
<mth>
if I use a git URL in a buildroot package, I can pass the branch via the version field, but it only works when it is the default branch
<Jay7>
I can't do that because of my budget weakness :)
<mth>
does OpenWRT work in the same way?
<mth>
I could specify origin/<branch_name> to work around it
<mth>
but I'd like to know if it's a bug or not
<xMff>
mth: you're reffering to package makefiles?
<xMff>
*referring
<mth>
yes
<mth>
I'm trying to add a gmenu2x package for OpenDingux
<mth>
from the "install_locations" branch
<mth>
while "master" is the default branch
<xMff>
hm
<xMff>
well
<mth>
after the clone, there is both "master" and "origin/master", but "install_locations" exists only under "origin/" and not locally
<xMff>
opewrt does:Â Â git clone $URL $SUBDIR; cd $SUBDIR; git checkout $VERSION
<mth>
not exactly, but roughly yes
<xMff>
yes exactly, its coded that way in include/download.mk
<mth>
the exact command it executes here is: git  archive --format=tar --prefix=gmenu2x-install_locations/ install_locations | gzip -c > /tmp/gmenu2x-install_locations.tar.gz
<xMff>
no, that is just for packing up the checkout later
<xMff>
the initial source download is as written above
<mth>
it doesn't do checkout, only clone
<xMff>
yeah well, I'm a svn guy
<mth>
and the branch is specified to the archive command
<xMff>
I have no clue about git, sorry
<xMff>
my checkout is your clone
<xMff>
so how does one switch a branch in git?
<mth>
with "git checkout"
<xMff>
in this case you can inject the branch name through the version field
<mth>
but it doesn't have to switch since apparently the "git archive" command can archive any branch, not just the current one
<xMff>
after wiping the cached tarball in dl/
<xMff>
then call make package/gmenu2x/{clean,compile} V=99
<mth>
thanks, that's useful
<mth>
although it doesn't answer the original question
<xMff>
this one? "(00:58:56) mth: if I use a git URL in a buildroot package, I can pass the branch via the version field, but it only works when it is the default branch"
<mth>
the problem is that just <branch_name> doesn't exist if the branch is non-default
<mth>
and specifying "origin/<branch_name>" will probably cause trouble with this string being substituted in file and directory names
<xMff>
ahh
<mth>
so I guess this is a bug in buildroot?
<xMff>
I'd rather call it a limitation :)
<xMff>
actually I wonder why the version is passed to checkout if its for switching branches