From: "Jörn-Ingo Weigert" <jiweigert@gmail.com>
To: development@lists.ipfire.org
Subject: Re: Updated Updxlrator and other changes
Date: Mon, 28 Jan 2013 15:13:32 +0100 [thread overview]
Message-ID: <t2a0hgjsokii024t8i0ky01t.1359382116060@email.android.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 9851 bytes --]
Great that you merged it for 2.13 :)
There is are one minor glitch for the status icon (showing parts of another icon cause of missing div) in the "anstehende uploads" table and the delete icon.
For this i will send a small patch later this day.
Kind regards,
nightshift
Michael Tremer <michael.tremer(a)ipfire.org> schrieb:
>In case this should be shipped with IPFire 2.13, this has to me fully
>merged by today!
>
>We are just finished with all the things, that we had to do for RC1,
>which is about to be released this week. After that, we cannot take any
>changes that are anything else than bug fixes.
>
>Michael
>
>On Mon, 2013-01-28 at 12:21 +0100, Jörn-Ingo Weigert wrote:
>> Any update on this for merging or test results / bugs?
>>
>>
>> Kind regards,
>>
>>
>> nightshift
>>
>> 2013/1/9 Jörn-Ingo Weigert <jiweigert(a)gmail.com>
>> That would be nice when it could be integrated in a 2.11
>> Core66 ;)
>> Before that it will be great when the developers could check
>> their UI-Addon-Interfaces.
>>
>>
>> Before the my patches all browsers where regardless of the
>> used DOCTYPE in a quirks-mode of xhtml.
>> So with these patches the xhtml-strict now really get into
>> work, with the side-effect that maybe some Addon-pages
>> are not well working as designed (maybe links not clickable,
>> etc).
>>
>>
>> These errors are mostly caused by misplacing Tags,
>> UPPERCASE-type of it or using depricated or misused attributes
>> or Tags like <FONT> which are really depricated in XHTML 1.0.
>> Those kind of errors are easy to find with the W3C-Validator
>> and more easy to fix.
>>
>>
>> For the ui of updxl I just needed 1 hour to find and fix those
>> general errors, and a "little" bit more (a lie but sound
>> good ;) ) to optimise it for an more CSS-based layout.
>> If the general errors are fixed that would be enough.
>>
>>
>> Did anyone test it and have some results if the changes I made
>> work or work not on their machines or have any degressions
>> elsewhere?
>>
>>
>> Kind regards,
>>
>>
>> nightshift
>>
>> 2013/1/5 Michael Tremer <michael.tremer(a)ipfire.org>
>> Hello,
>>
>> thank you very much for the patches you sent in. I had
>> a look at them
>> and they look fine (did not read through all the perl
>> code).
>>
>> Patches 0005 is a duplicate of 0004.
>>
>> Who is now going to merge them to the git repository?
>> I am running out
>> of time to do that.
>>
>> I reckon the changes won't make it to IPFire 2.13,
>> which is done by now.
>>
>> Michael
>>
>> On Mon, 2012-12-24 at 09:24 +0100, Jörn-Ingo Weigert
>> wrote:
>> > Hi Michael,
>> >
>> > 2012/12/23 Michael Tremer
>> <michael.tremer(a)ipfire.org>
>> > Hi Jörn,
>> >
>> > could you please provide patch files against
>> the current
>> > development
>> > tree, so we can review the changes you made
>> more easily.
>> >
>> > Done, I'm not so familar with git and RCS in
>> general, so take it easy
>> > and the files attached.
>> > don't know if git added the extra giffiles so added
>> it too. put them
>> > into html/html/images/updbooster dir.
>> >
>> > Well, the WUI is not conform to any HTML
>> standard, because too
>> > many
>> > people have put their code into it without
>> agreeing on a
>> > coding style.
>> >
>> > Well, I oriented me on the existing XHTML-Doctype in
>> the current
>> > header.
>> >
>> >
>> > I personally consider this as a full-time
>> job to fix all
>> > problem that
>> > there are and so, I don't want to put more
>> time than necessary
>> > into it.
>> > Developing a new WUI from scratch is more
>> important to me.
>> >
>> >
>> > I agree with you, but hoping that coming versions of
>> browsers will be
>> > lazy as now in interpreting
>> > not correct formed (x)html should not the right way.
>> Better to point
>> > to the browser vendors then on our own code. ;)
>> > And its not much work (Hust) to test it with online
>> validators.
>> >
>> > > 1. apache:
>> >
>> > > Modified /etc/httpd/conf/loadmodules.conf
>> - enable
>> > mod_deflate for
>> > > compression the output files (except
>> graphics) if browser
>> > supports it.
>> > >
>> Modified /etc/httpd/conf/vhosts.d/ipfire-interface-ssl.conf
>> > - enabling
>> > > compression for whole SSL-Web interface
>> >
>> >
>> > Yeah, we can accept that one. Please send
>> the patch.
>> >
>> > Great :)
>> >
>> >
>> > > 2. Theme "ipfire" & "maniac":
>> >
>> >
>> > > ....
>> >
>> >
>> > > These changes let perform google chrome
>> like a charm
>> > rendering the
>> > > pages within ~15 secs like other browsers
>> (tested with IE9,
>> > Opera,
>> > > Firefox in actual versions)
>> > > instead of waiting for minutes ...
>> >
>> >
>> > In case that does not break anything with
>> older browsers, send
>> > a patch
>> > as well.
>> >
>> >
>> > I didn't test it with IE <=7, or NNavigator nor
>> MOSAIC ... well let's
>> > see.
>> >
>> > > 3. Web-UI in general and addons which use
>> the "age"-function
>> > from
>> > > general-functions
>> > >
>> > >
>> > > - modified age function to show the time
>> translated, in
>> > single and
>> > > plural terms, but only the parts, which
>> make sense.
>> > > Example instead of showing: 0d 0h 47m
>> 15s, it will show
>> > now: 47
>> > > Minutes, 15sec. in connection time
>> >
>> >
>> > I don't think that it makes any sense to
>> print "minutes"
>> > instead of "m"
>> > because there is not enough space to do so.
>> >
>> > I agree that it makes sense to omit "0d" and
>> "0h".
>> >
>> >
>> > Well, it prints out only the first part in long
>> form, all followed
>> > will be shortened
>> >
>> > Examples
>> >
>> > Old: 1d 2h 3m 4s
>> > New: 1 Day, 2 Hr, 3 Min, 4 Sec
>> >
>> > Old: 0d 0h 1m 2s
>> > New: 1 Minute, 2 Sec.
>> >
>> >
>> >
>> > Yes there is, because those files have been
>> changed recently.
>> >
>> > I see.
>> >
>> > -Michael
>> >
>> > Hope, this work now..
>> >
>> > Kind regards,
>> >
>> > nightshift
>>
>> > _______________________________________________
>> > Development mailing list
>> > Development(a)lists.ipfire.org
>> > http://lists.ipfire.org/mailman/listinfo/development
>>
>>
>>
>>
>>
>
next reply other threads:[~2013-01-28 14:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-28 14:13 Jörn-Ingo Weigert [this message]
2013-01-28 15:33 ` Michael Tremer
[not found] <CAAiW7AemvOF5y_pxnSsmy98mJmjOveGfSK2jCZhven1bh=bqwg@mail.gmail.com>
2013-01-28 13:11 ` Michael Tremer
[not found] <CAAiW7AdEsKJB0AKM+x8zBy5Vf5HFEkSstO_hrSMbO8nkX7NrgA@mail.gmail.com>
2013-01-05 12:37 ` Michael Tremer
[not found] <CAAiW7Af9ifdV4xW3NonEq9QDkj=-wHgiP43NN3eTqwD5mQdqwA@mail.gmail.com>
2012-12-23 12:43 ` Michael Tremer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=t2a0hgjsokii024t8i0ky01t.1359382116060@email.android.com \
--to=jiweigert@gmail.com \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox