Bug#387470: debian-installer: needs an possibility to load a full font for g-i

Package: debian-installer
Severity: normal

Hi,

ttf-cjk-compact-udeb and some other font packages for
graphical-
installer have only limited characters by size problem.

But because debian-installer is dynamic system, it's hard
to assume what new debconf messages appear (especially after
running
tasksel and aptitude).
If new message has an new character, graphical-installer
will
show a broken character or just miss it.
I believe graphical-installer has to load "full"
font file at
least before running tasksel.

Although I understand fixing at this time is too late, I'd
like
to add this bug to our TODO for Etch+1.

Thanks,
-- 
Kenshi Muto
kmutodebian.org


-- 
To UNSUBSCRIBE, email to debian-boot-REQUESTlists.debian.org
with a subject of "unsubscribe". Trouble?
Contact listmasterlists.debian.org

Damian Minkov wrote:
> Hi,
> 
> I'm experiencing some problems implementing 
management of groups in 
> Jabber protocol.
> Here the groups have some differences regarding the ICQ
groups.
> 
> 1. If a group is empty after logging out and logging in
back this group 
> is disappeared.

Well, if someone has created a unresolved group - we could
issue a 
GroupRemoved event. Otherwise - we don't care.

> 2. Contact can be in many groups

OK. we could simply not support this feature in the
sip-communicator to 
simplify things. (This is also in answer to your other
mail).

> 3. Events are received only for changed entries
(buddies in the contact 
> list)
>      From them you must consider what to do.
>     For example renaming a group - what happens.
>     - if this group does not have entries in it -
nothing happens.
>     - if it has - you got entriesUpdated event for
every entry in the group
>        from there you must see that a new group is
created
>        and after that must see if any group has no
members - that must 
> be deleted.

I think you could simply mimic the same behavior in the
sip-communicator.

1. When you get an entryUpdate event you check whether the
new group 
exists.
2. If that is not the case you fire a new group event.
3. Next you move your local contact instance to the new
group and fire a 
contact moved event.
4. After every ContactMovedEvent you verify whether there
are other 
buddies left in the old parent group and if this is not the
case you 
fire a group removed event and remove your local 
ContactGroup instance.

Is this ok?

>     Here is the doc of the method group.setName()
>          Changing the group's name is like moving all
the group entries
>          of the group to a new group specified by the
new name. Since 
> this group won't have entries
>          it will be removed from the roster. This means
that all the 
> references to this object will
>          be invalid and will need to be updated to the
new group 
> specified by the new name.

I think this should also work if you follow the scheme from
above.

> For now when I create a group I fire event for that
immediately, without 
> waiting for notification from server (there is no such)

ok

> Other interesting thing is that you can have unfiled
entries, entry that 
> doesn't belong to any groups )

Great, then you could store as unfiled all contacts created
with a null 
parent group.

Does this make sense?

Emil



> What you think ?
> 
> damencho
> 
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
> 
> 

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net